Skip to main content

Tag: Training

The Purpose, Scope, and Value of a Six Sigma Project

Six Sigma is a collection of tools and techniques that are focused on eliminating defects in a product, process or a service.

It is a disciplined and data-driven approach. It was developed by Motorola based on the fundamentals of quality management. The six sigma process includes many activities like measurement, improvement, and validation. It emphasizes the relationship between the performance of the product and the corrections that are required during the manufacturing of the product.
Six Sigma projects are used to measure the cost of improving the processes that are producing substandard products or services. Whether in service or manufacturing industries, these projects quantify the effect of process changes on delays or rework. The aim of each Six Sigma project is to produce statistically significant enhancements in a particular process. These projects use suitable tools within the Six Sigma approach to producing financial benefit and improved performance of processes or services.

The purpose of a Six Sigma Project:

As the cost of material is rising and the competition is increasing day-by-day, organizations look for techniques that are capable of increasing the efficiency of their projects. Six Sigma projects focus on improving the efficiency of the organizations. By implementing the Six Sigma methodology, an organization can enhance the efficiency of their products, processes or services through identification and resolution of product or defects that might affect the organization and minimize the variation within the process. Every Six Sigma project follows a defined series of steps which include specific targets for improvement. Few examples include:
● Reduction in the process cycle time
● Reduction of scrap generated by a process
● Increasing customer satisfaction
● Reduction in the number of factory defects
● Reduction or elimination of costly reworks

The scope of a Six Sigma Project:

Project scope is a part of the Define phase in the DMAIC process and is included in the Project Charter. A project scope describes the limitations of a project. It keeps the team in alignment, on purpose, contained, focused, and motivated. The project scope might include:

● Beginning time and end time of the project
● Duration of the project
● Process boundaries of the project i.e what is within the scope and what is outside the scope.
● Sub-processes involved in the project
● Product lines of the project
● Locations involving the divisions, states, territories, and countries.

The most important component of the project scope is addressing the beginning and the end of the project. This is often outlined in the SIPOC diagram.


Advertisement

Importance of defining the scope of a project:

● The project scope explains what the project involves so that all stakeholders can understand what is involved
● It provides a roadmap to the managers in order to assign various tasks and schedule work and budget appropriately
● It helps the team members to focus on common objectives
● It prevents complex projects from extending beyond the fixed vision

How to define the scope of the project:

The criteria under which the scope of the project is defined is:

1. Deliverables: The end project delivered to the user and the deliverables generated by the project itself. These are called internal and external deliverables.
2. Data and functionality: Licensing agreements, payment processes, and customer management.
3. Technical structure: The focus of the project on infrastructure.

The value of a Six Sigma Project:

The value of a six sigma project is defined as the business case of a project. It is a document that uses the problem and goal statements of a project and converts them into a business value statement. There are five different cases:

● Strategic case – It is a compelling case for change that suits the strategic goals of the organization.
● Economic case – It is the solution that represents the best value for the problem.
● Commercial case – It is the recommended solution that is attractive to the market and can be obtained using suitable terms so it is commercially feasible.
● Financial case – It is the proposed financial investment that is affordable.
● Management case – It is the input required from all individuals involved in the project.

The steps to write a business case for a project:

The steps to write a business case are as follows:

1. Research the competition, market and any other alternatives for a project.
2. Compare it with the other approaches and finalize it.
3. Compile the final data and
4. Document

In addition to the above metrics, six sigma projects have seven different responsibilities. These are:

1. Leadership: The team defines the goals and the objectives in a six sigma process.
2. Sponsors: They are the individuals who understand what six sigma is and are dedicated to its successful implementation. They solve problems which might occur during the process.
3. Implementation Leader: These are the individuals who are responsible for supervising the team effort. They support the leadership team by ensuring the timely completion of the processes.
4. Coach: An individual who is an expert or consultant in Six Sigma who sets a schedule for the team and resolves any conflicts among them.
5. Team Leader: The person responsible for managing the team. They also act as a medium of communication between the sponsor and the members of the team.
6. Team Member: The individuals who work on a six sigma project. They have specific roles and work collectively with other team members.
7. Process Owner: The person who is responsible for the management and monitoring of various processes after the team has completed their work.

Six Sigma methodology focuses on a better understanding of what the customer requirements are and how the quality of the products delivered can be improved. It concentrates on waste reduction and cost reduction.

Top Tools for Successful Business Analysts

In order to be a great business analyst (BA):

Knowledge of the business, understanding the technical aspects and a capability in the tools of the trade are all key to ensuring high-quality software is delivered on time and as per spec.

A complicated role, BAs within the ICT sector decode the client’s business requirements into carefully considered technical specifications that software engineers use to develop what the client is asking for.  

Nosipho Rakoma of BBD, a BA at a leading software development firm, explains that “many of the clients I’ve worked with have their own preferred tools. The trick is to immerse yourself in the client’s operations and be flexible in your knowledge and approach of the tools BAs can use”. She adds that although BBD favours an Agile mindset, project teams are encouraged to work in a manner and with the tools that are most suited to each client environment.

Here is a list of the top five tools BBD BAs love to use:  

1. Jira and Confluence

Jira and Confluence form part of the Atlassian stack and are powerful collaboration software programs that allow for an open and shared work space that helps you manage the details within a project without losing sight of the big picture.  They also enable you to create a single source of truth for your software documentation, while helping ensure easy communication between BAs, test analysts and the software engineers.  

Although originally designed for Agile development teams, this update-as-you-go software is useful for BAs no matter their team’s methodologies or mindset. Rakoma believes that with the world looking to Agile, aspiring and experienced BAs need to be comfortable with these types of tools.


Advertisement

2. Microsoft Visio

As diagrams depicting project dependencies and schedules are an important element in a BA’s project manager or scrum master role, the Microsoft Visio diagramming tool is excellent for remaining on top of all of the moving parts within a project.

For everything from workflows to process maps and network diagrams, this powerful visualisation tool helps display and drill into the project elements. This is beneficial for BAs because it helps maintain a clear overall picture, and aids in easier execution and communication with both technical and non-technical team members.

As part of Microsoft Office, Visio shares functionality with Excel, Access and Word.

3. Enterprise Architect (EA)  

EA is a full cycle online modelling tool with built-in requirement management capabilities. Made for business and IT systems, it allows real-time, embedded development and the all-important version control. The beauty of this tool is that for distributed teams, where not every member sits in the same office, managing tasks, responsibilities and dependencies doesn’t become an issue.

4. HP QC

The HP Quality Center is quality management software boasting requirement and test management, and business process testing for IT environments. HP QC is a component of the HP application lifecycle management software solution set and is good for day-to-day tasks. Although face-to-face time is important in development teams, some BAs find this tool especially helpful because it can often help save time so that your meetings are only about what’s most necessary (you know, for all those times the meeting could have been an email).

5. Video conferencing

Because you don’t have to be in the same location to deliver, and often aren’t, video conferencing tools such as Zoom, Appear.In and Rocket.Chat can be exceptionally helpful for project delivery teams. Because BBD has a global footprint, with teams sitting in different countries, video conferencing makes daily stand-ups and team meetings that much easier. Additional tools worth a mention include Trello and Excel.

Rakoma concludes that change is hard, and changing your toolset is especially so. But there is truth to the adage that if you’re not changing then you’re not growing because growth in the ICT sector means more opportunities. 

Making the Most of BA Training

One topic that is relevant for us as BAs wherever we are in our career is the topic of professional development.

Professional development is relevant for those joining the profession, who need to get to grips with the core skills, as well as those who are experienced who need to refresh their knowledge or keep up to speed with new techniques or developments. Business analysis is an evolving field, and staying up to date is absolutely crucial. Continuing professional development takes a number of forms, both formal and informal, can include anything from reading blogs and articles (on sites such as BATimes.com), attending IIBA chapter events, participating in webinars, mentoring, running or attending ‘lunch and learn’ sessions and of course attending a specific BA training course.

At this point, those of us that have been around for a while will probably be rolling our eyes. I’m sure we’ve all attended or have been sent on the occasional training course that hasn’t been effective. It’s very easy to attend a training session that is logically designed, fun to participate in, but that makes absolutely no difference to our day-to-day practice. You might have even been on courses where the only highlight was the coffee and doughnuts.

It absolutely doesn’t have to be this way! Training, alongside other professional development activities, can be useful and effective, if we plan effectively. Here are some points worth considering.


Advertisement

  1. Use BA techniques to establish the need: We have a whole range of BA techniques that can help us establish needs and requirements in an organizational setting. These same ideas can be used for an individual or team too. We can turn our analysis on ourselves and carry out a SWOT analysis, understand key skills gaps, and then translate these into requirements. If we notice a particular skills gap in our team we can then research, assess and decide amongst multiple options for plugging that gap.
  2. Training isn’t the only solution: As discussed above, training is by no means the only ‘solution’ to a skills gap. It’s easy to overlook the wide range of resources at our disposal, and often there’s a wealth of experience that exists within organizations. If you are lucky enough to be part of a Community of Practice, it may be that you can use Community of Practice meetings to exchange knowledge and build skills in a safe environment. Training is absolutely useful, but it is most useful when blended with other techniques that support it.
  3. Own the plan: As BAs we need to own our own professional development. Even if you are lucky enough to work for a company that will send you on training, it is still worth having your own (personal) development plan, based on your own goals. Of course, like all plans, it should be malleable and fluid—but it shows the broad direction of travel at any point in time, and this can help figure out immediate next steps.
  4. Choose the provider carefully: If you are booking external training, be selective with the provider you choose. Ask questions like “will the trainer be an experienced BA?”, “When was the last time they worked on a project assignment?”. If you are running the course on-site for your team you might want to ask “Can you customize this course so that it is relevant for our context?”. Ask around your colleagues and network to find out which training providers they would recommend.
  5. Training starts before the day itself: Training is likely to be even more effective if we are able to come prepared with ideas, questions and ‘real life’ dilemmas and situations to discuss. Keeping why we’re attending the training in mind, and assembling these ideas in advance can be very helpful.
  6. Commit to action: During the training, after each technique or concept is covered, it is worth consciously considering aspects such as:
    • In what situations can I use this?
    • When is my next opportunity to use/practice this technique?
    • What are my next steps?
      Using a brand new technique in a radically different way for the first time is sometimes tricky, so you might choose to use it in a team meeting, or some other ‘safe environment’ first. More routine techniques can be picked up straight away.
  7. Ask ‘when will I revisit or re-read my notes’?: Learning can be great fun, and revisiting old training material can help us to refresh, reflect and jog our memories.

Training can be a useful professional development tool when chosen carefully and executed well. Questions such as the ones above can help us in choosing the right course and getting the most from it. I hope that you have found this useful, please do get in touch with any other tips that you have—I’d love to hear them!

5 Project communication mistakes.

Business analysts can get so lost in the details of the projects that we forget to tell the people who are most affected.

Or, we try to tell them but they don’t quite understand. Or we just talk to senior stakeholders and ignore the rest. 

Here are five ways communications can go wrong.

1. Treating communications like a luxury

The change manager – or dedicated communications officer on big programmes – is often the first to be cut, if indeed the investment has been made in hiring one to start with. The logic here is that running a good communications operation is secondary to delivery activities and, in one memorable case, I’ve heard clients refer to such roles as ‘walking headcount’, meaning their days are numbered.
However, as many teams quickly find out, there is very little on a project that does not fall within a communications officer’s remit: obvious work such as keeping end users informed of a project’s progress and probable impact but also vital but more subtle work like managing different types of stakeholder, creating alignment in messaging, getting buy-in and support. Without this, most BAs managers quickly find themselves sinking and having to dedicate much of their time to this work – taking it away from ‘delivery’. 

2. Failing to manage tricky customers effectively

As every contractor, consultant or internal BA knows, stakeholders can be a difficult crowd. Personalities vary, irrespective of seniority: one likes detail and weekly updates, one just wants the headlines and a quarterly steer co; another refuses to read emails but claims to have not been informed; others vie for political advantage over their colleagues at the expense of all other agendas.
Ineffective strategies for dealing with these situations include ignoring difference, trying to pander to everyone or taking the situation personally rather than seeing it as a communications challenge. Through this lens, all inter-personal friction can be mitigated and every stakeholder can be managed; indeed, the only failure is to give up and stop trying new approaches.


Advertisement

3. Creating an information vacuum, allowing gossip 

Many projects become their own worlds, often seeing the multitudes of stakeholders who will ultimately be affected by the project’s outcome as an afterthought. Well, people talk and a lack of information will be addressed through gossip. Before you know it, stakeholders will believe your project has nefarious goals or – perhaps worse – that you are going to make all of the organisation’s problems go away.
Clear communications are the only way to manage this, ideally presented by a client stakeholder with good rapport with the affected groups. 

4. Being boring

We go to work and – for whatever reason – we think everyone else suddenly wants to be bored out of their minds. So we fill our emails with tired jargon or we inflict long PowerPoint presentations on our colleagues or we feign enthusiasm in the hope our project team will feel motivated. But, our brains in the office are the same as they are outside the office: same attention span, same interests, same intelligence. Not using this fact and communicating in a similar way to how we are accustomed outside the office is a mistake that is sure to see your message being lost or ignored.
Business analysts are particularly culpable. Sometimes, we manage to be both dull and over-bearing to our stakeholders – or try to inject ‘fun’ that numbs the mind of on-lookers. The best approach here tends to be to deliver simple messages, ideally with no more than one or two slides in support. With so many free third party tools available, many of us could also consider playing with well-formatted html emails, infographics, video presentations; but it is rare such media replace the strength of a solid and impactful presentation. 

5. Being slow

Many projects that do have a dedicated change officer responsible for communications spend a long time devising a strategy, defining which communications go to which people at which times. This is useful in principle but often they are encumbered by having to get approval for the plan – or individual communications – from unavailable stakeholders or of over-ambitious and costly strategies that end up either never being implemented or rushed at the last minute. Communications are, by their nature, newsworthy – and news must be delivered while it is still new.
Business analysts on projects of all sizes need fixes for these issues to allow them to focus more on the day-to-day running of their projects. If you want to explore ways to address these issues and manage your communications allowing more time for higher-value project activities, please feel free to reach out to the writer of this article.

Live at Agile 2017 with Kupe

Kupe is at Agile 2017, the premiere agile event hosted by Agile Alliance.

He is writing daily blogs on topics that relate to you, project managers and business analysis professionals. We know everyone could not make it to Orlando, so Kupe is bringing Orlando to you. This is going to be one magical blog series. Keep a look out for all the updates this week. 


Agile 2017: KUPE’S VIEW – DAY 4

Orlando, Florida, August 10, 2017:  Day 4 was my last day at the conference. In case you don’t know, my goal in life is to meet everyone in the world.  Throughout the week I was meeting people left and right.  If you are a connector like me, this is a fabulous event. I created a little collage of some of the people I met and longtime friends I connected with. 
Agile2017SelfieTileKupe

This is my last post from Orlando. I hope you enjoyed the series.

Linda Rising- Moral Foundations Theory: To Help Address Conflict

The 2016 United States president election was a transformational moment for Linda. She supported Hillary Clinton. Linda was very upset with the election result. She found herself trying to figure out who voted from Trump. She couldn’t stop judging those that did vote for him. She couldn’t understand why. Friends she had for years, where now almost her enemy. It was really bothering her. She wanted to put people in a box. If you voted for Trump, she’d close the box. This was not healthy. This is not who she is or wanted to be. This led her to begin researching how people decide what is right and wrong and dealing with conflict.

Linda shared a lot of evidence on how people make ethical decisions and how we communicate with each other based on those decisions. She explained that when we are faced with conflict a natural reaction is a fight. We want to win. We stop listening, and just wait to reply. We view the problem being with them, not us. So, the first step in any conversation should be to listen like Stephen Covey suggests. You need to listen with the intent to understand.

There were some good books referenced that I thought you would enjoy reading. These were a few publications Linda used in her research.

  1. Thinking Fast and Slow – Daniel Kahneman
  2. Predictably Irrational – Dan Ariely
  3. Fearless Change – Linda Rising and Mary Lynn Manns

A key message was you need to be open to changing your view point. Begin with levels of agreement and focus on the other’s values. This creates more receptive listening in others, and shows empathy, lowering the conflict.

With the polarity in views regarding political parties, if your goal is to persuade others to your view, you will be disappointed.  Instead go into a conversation as you might change and you want to learn something.  Then you have an attainable goal.

If you are completely closed to changing your own point of view and learning, then don’t bother having the discussion. Confirmation Bias will filter everything, That is what is going on in this country.  We only see what validates our own point of view.

Trump vs. Hillary is not the only kind of conversation where this happens. The lessons shared by Linda apply to all personal and work conflicts. 

For more about Linda – www.lindarising.org

Dave Bieg and Joy Beatty – Agile BA Practices using the Guide to Business Analysis

I arrived late to Dave and Joy’s session, but I picked up on the overall theme of their session.

The core concept is teams need to collaborate and determine what approaches are worth doing to accomplished the goal of the project. Their session was workshop style having teams think through what tools and techniques are appropriate for both traditional approaches and agile approaches. A nice twist they added was how may you alter a technique to work in your situation.  

The tools and techniques covered are based on PMIs work on “the Guide to Business Analysis” which includes the “Standards for Business Analysis” that will be published in late 2017.

The guide mentioned above, provides guidelines, not rules or policies. Nothing is a must. When tailoring your approach, you should always be asking what value does a task add to me, my team or the business.

I did have one question for Joy and Dave, but did not get a chance to discuss this with them. Joy shared, and I am paraphrasing, that inputs and outputs for tasks in both agile and waterfall are similar. You just use some different techniques.  My question is “do you do the same work in both methods, just use different techniques?”. 

It was nice to hear that the process the team used to develop the guide included using agile language first. Then adjusted to make sure it was clear for those that use a more traditional approach. Joy explained that many writings take a traditional view first, then tack on agile. They did the opposite.

I have not seen early drafts of the guide from PMI. I guess we’ll have to wait until the fall/winter!

To connect with Dave and Joy – [email protected], [email protected]

Elizabeth Ayer – Spreading the Love: 8 Ways to magnify the Impact of User Research

Agile2 17 Kupe and ElizabethMy first observation from this session was that Elizabeth is a fast talker.  I was surprised because she is from Los Angeles and lives in the UK now.  She clearly won the highest energy level at the conference award. Her session was very pertinent to many at the conference. Most discuss the need to get with the customer to listen and observe their behaviors and uncover their needs firsthand. Unfortunately, most people don’t get the chance to do it. 

There was a time in her company that the Product Manager did all the customer interaction and would feed that information to the team. This was OK, but not great.  The problem was the development team was not fully in touch with customers. They had a development view and focused on how they thought the product needed to be enhanced. This is not as good as enhancing the product like the customer needed it enhanced. So, they switched things up.

The team started to follow a key principle: Involve more people. Learn as a team, don’t hand something over.  Certain customer engagements needed to be done as a group. Here are the 8 concepts she shared.

For the development team: 

  1. Support existing priorities – Don’t forget about things that people are already worried about – address it. The team feels pressured for time already. Help them focus on the following information from the customer.
    1. How much is enough, how is the user solving the problem today, how should we test this?
    2. Her team created a column on their story board called “What we don’t know”. This gave everyone the ability to put up what they needed to learn so they can focus the calls with customers. This helped focus the calls.
  2. No more UX virgins – Everyone does this.  No one gets a free pass.  You need to watch your users use the system.
    1. Make it safe and easy for people not wanting to interact with customers. Example time…they had developers on calls sitting at their desk on a video call.
  3. Everybody is active. Everyone has a role to play in meetings. (Call leader, plan checker, wingman to leader, bingo scorekeeper (ha!), product expert, note-taker)
  4. Agree for interpretation – Get a shared understanding. After the meeting debrief and make sure everyone is on the same page.

Extending beyond the team:

  1. Make it available. Write it down.
  2. Publicize the work. Allow people to consume at their leisure – More of a pull method, not a push method. 
  3. Offer your sessions. Allow other people to join if they want to hear/see. Or they may need other information from the customer. Tack on their needs at the end.
  4. Name drop your users.  Bring in names to conversations to make it real. Don’t forget about the customer.

Wait…what about personas? Isn’t this enough?  Elizabeth made a great point. She shared many teams just think of personas or use the voice of the customer. Her point is why not actually hear the voice of the customer. And with personas, you can lose some of the finer points.  Not everyone is the same.  Maybe personas first…then get to the individuals.

To follow Elizabeth – @ElizAyer

Evan Leybourn & Shane Hastie – If you need to run a project, you’ve already failed – #noprojects

There were PMs in the room so I was excited to see how this one was going to go down. This was all about the No Project movement. Evan shared a long history of projects. The beginning started in 1698. I had no idea. A key lesson is that projects focus on the wrong thing. They focus on what is measurable and not what is valuable. Projects are temporary. On the other hand, products aren’t. Shane continued sharing that projects are expensive. There are typically overruns and opportunity costs. Studies show typical projects could be 172% over budget and 184% over time. This could show we are just bad at estimating!

What we need is a continuous culture. We need continuous delivery. To help with this approach, enter  #noprojects. The definition of #noprojects is the alignment of activities to outcomes measured by value. Constrained by guiding principles and (optionally) supported by continuous delivery technologies. The last part was optional because value is not always derived from a technology initiative.

A different line of questioning helped me understand where they were headed. Instead of asking “how much will it cost?”. Ask, “how much is it worth?” If you focus on cost then a project goes until all the features are done. And, as was stated earlier, projects go over budget all the time.  A #noproject should stop when you get to a point when value flattens out. By asking what is it worth gives you the guidance on how much to spend.

The concept is to have a value delivery team. This is a dedicated, stable, cross functional team that contain the required skills to achieve value. The team is trusted to make operational decisions, and value can be continuously created.

Full disclosure. This was a deep topic. A complete reframe for most. My feedback to the conference organizers is to put these types of sessions at the beginning of the week!

To follow Evan and Shane – @eleybourn @shanehastie


AGILE 2017: KUPE’S VIEW – DAY 3

Orlando, Florida, August 9, 2017: Day 3 had an interesting observation. Tuesday night (Day 2) was filled with many vendor parties. This resulted in a tired day for many. I saw more people hanging in the lobby areas than the days before. This may not have anything to do with those parties, but that’s my conclusion! I did not attend any of those parties as I was speaking at the Central Florida IIBA chapter. It was a great event.

First up for Day 3 was a keynote presentation with the main subject of DevOps. Let’s go!

Jez Humble – Continuous Delivery in Agile

Beware, this starts off with a technical topic. It ends with advice that applies to any change. What is continuous delivery? When you hear DevOps, think continuous delivery. The definition shared by Jez is, ‘The ability to get changes – features, configuration changes, bug fixes, experiments – into production or into the hands of users safely and quickly in a sustainable way’.

Jez explained that a high performing IT organization does the following things well.

  1. Lead time to changes – Keeping the lead time to implement changes down for the highest priority at a moment in time.
  2. Release frequency – Release as frequently as possible/acceptable.
  3. Time to restore service – If something goes wrong, get it back up quickly.
  4. Change fail rate – Reduce the amount of fails when released.

The first two have to do with deploying fast. The last two are about deploying with quality. You don’t have to have one without the other.

The challenge explained was that many organizations are not great at all four. Why can’t we do continuous development in a fast and safe way? Here are the stated reasons by teams.

  1. We are too regulated.
    Bad reason. Amazon is a regulated company deploying every 11.6 seconds. Not easy, but it can be done. Jez did it with the Federal Gov’t. What’s your excuse?
  2. We are not building websites.
    The division that manages HP printer firmware improved their deployment schedule. By the way, firmware is not a website.
  3. Too much legacy.
    You can do test automation with legacy mainframe systems. It has been done. Jez played a video from BMC Software that showed a team running automated tests with a mainframe system. They did not think they could do it, but they tried and it worked.
  4. Our people are too stupid
    It is usually not stupid people. Steve Denning says a bad system will beat a good person every time. Is it the people or is it the system/culture?

Jez wrapped up by saying those reasons are not the real reasons why deployment can’t be improved. The actual reasons are:

  1. Our culture sucks
  2. Our architecture sucks

I think this relates to most changes. As mentioned earlier, culture will eat good people and ideas for lunch.

For more about Jez – Check out his author profile.

Me – Radio show with Agile Amped

Kupe 08102017 2I was honored to be asked to do a 30-minute segment with Solution IQ’s Agile Amped Radio Show. Guess what I talked about? Improv and networking…who could have guessed? I will have a link in the next week or so. Or you can subscribe to their channel here, https://www.solutionsiq.com/agile-amped/.

Thanks to the great host, Howard Sublett!

Amy Silberbauer – Do we still need Business Analysts and Systems Engineers? Now more than ever!

Kupe 08102017 3

Amy had a 30-minute session and packed in a lot of great information. One of the main reasons for needing people with business analysis experience is that enterprise success is not just about faster delivery. It is about making a happy customer. Basically, you want to deliver fast stuff that makes customers happy. Not just delivery fast stuff. Amy uses the term “time to happy customer” instead of “time to achieving value”. In the end, the goal is a happy customer. Value can be different for different groups. This is a way to address success at a higher level.

A good example given was a customer needing something to mix food. Can that need can be solved with a spoon or a Cuisinart? The BA and systems engineer need to find out. A Cuisinart may be cool to deliver, but it may not be needed. The key to success is understanding the customer.

In today’s environment, we need designers to build the system. There are competing and disconnected interests and needs. The BA can help design a unified vision and goals. This is the synthesis of information and connecting the dots to design a complete system.

Organizations need design thinking. Amy urged BAs and system engineers to get in this space. She then shared a slide titled “BAs and SEs are the new sheriffs in town” The message: there are roles for people in these roles. It is just slightly different going forward. Here are the 4 options she highlighted.

  1. Customer Advocate – Be the “face” of the organization. Tease out the real requirements. Get continuous feedback, keeping the customer “in the loop”.
  2. As Designers – Define the solution. Understand roles and personas. Elaborate end-to-end solution use cases and activities within them.
  3. As Orchestrators – Take a Systems View. Apply economic thinking to define MVP and iterative delivery plan. Collaborate with engineering to determine best alternatives.
  4. As Engineers – Propose and evaluate alternatives. Explore and validate technological assumptions.
  5. As Architects – Define common architectural and technical vision. Ensure consistency.

Connect with Amy – https://linkedin.com/in/amy-silberbauer-3a102043

Angela Wick – Value – Perspective is Everything! @WickAng

Kupe 08102017 1How do we know we are delivering value, not just delivering things faster? That’s the question Angela was covering in her session.

Before I get into some of the highlights from her talk, check out this list of questions to ask about value.This is a great starting point.

Value is not just ROI (return on Investment), it is about the value to the customer. Does the customer love the product? The good thing is Angela and Amy are saying the same thing!

I really liked David Hussman’s Dude Law that Angela introduced to the group. It’s n easy formula to determine you are spending enough time on determining value. The equation is Value = Why / How

We should be talking more about the Why, then the How. So, the higher the number, the more time spent on value conversations over how we are going to build a solution. Use this as a good indicator of getting too deep in the weeds before you gained a shared understanding of the value you are trying to achieve.

Her next set of slides I am sure causes some good debates in a room filled with BAs. Not as much in a an agile world. The slide was titled, “Is a BRD valuable?”. The key takeaway is we should be moving away from big thick documents. Think about what documentation will help with. Don’t just document for documentation sake. A great point made was if your team is building things in smaller chunks, then you are dealing with less requirements. So, you can remember the requirements. Putting things up on visual boards making things visible for the team is a more effective way then packing things in a document that is harder to access.

I’ll end with a key message. I know his may sound simple, but it seems to get lost. You have to make sure you know who you are building the solution for. That’s the group you need to be considering when determining value. You should identify a primary customer or persona, secondary personas and tertiary personas. When designing a solution start with making sure it works for the primary persona. Then check to see if it works for the secondary and tertiary personas or can it disenfranchise those personas. Then make a decision if a redesign is necessary.

For more about Angela – http://www.ba-squared.com

I want to end with a random conversation I jumped in on discussing neuroscience and the impact when we are threatened. The basic concept is that if we are threatened, the thinking part of our brain shuts down. So if we are pressured at work to get stuff done we are most likely going to produce lower quality work. Yesterdays sessions talked a lot about safety. When in a safe environment, the thinking part of our brain is on fired.

Day 3 was awesome. Day 4 starts now…gotta run!


Advertisement

AGILE 2017: KUPE’S VIEW – DAY 2

Orlando, Florida, August 8, 2017: Day 2 at the conference was another success. I attended some great sessions and was the speaker in one. I’ll give a little recap of my talk, although Claire Moss was doing some great live tweeting. Her handle is @aclairefication and is also tweeting for Agile Alliance using @agilealliance. If you are on twitter you can keep up on some sessions in the moment by following Claire.

First up for Day 2 are some familiar names. Here we go!

Kent McDonald and Heather Mylan-Mains: How to Find the Real Need with Socratic Questioning

One thing that always comes up in our profession is “what questions should I ask?”. Managers need to know their teams are asking the right questions. Well, Heather and Kent to the rescue. By teaching attendees Socratic Questioning they were giving them an approach to get the true need for a project. Too often, the solutions built don’t address the real problem or opportunity. Example time – Heather told a story about a young boy being hit by a car on a street in the boy’s neighborhood. The solution implemented was installing speed humps which cost almost $300,000. You would think the real problem is people are speeding on the street. Nope. The accident happened at 9 pm on Halloween. The driver was not charged with speeding. It was just a tragic accident. Speed humps were the wrong solution. Something more like better lighting, blocking streets off during Halloween, and the like would have been better approaches. How often are you building “speed humps”?Kupe 08092017 1

The Socratic Questioning method is to help someone come to a conclusion by asking a series of questions. Great uses of the approach include identifying the real need and coaching. Here are the 7 questions they suggested asking to get to the real need.

This is a starting script. You don’t have to stick with it in this order…be ok adapting.

  1. What is the project Great question to get the conversation started?
  2. When did you realize you needed to do this project? Ask for scenarios to find out what’s happening. You want to make sure you know what happened that sparked this idea for a project.
  3. What problem is this trying to solve? Could cause uncomfortable silence. They may not know the answer. That can be revealing. If they can’t come to an answer, maybe the project is not worth it.
  4. What is the impact to your organization? Is it worth solving
  5. How much is that problem costing your organization? Is it big or small – how much should we spend to fix the problem?
  6. How should tomorrow look after we’ve solved the problem? What does success look like? You may be able to fix the problem another way or with less effort.
  7. What are the next steps? – What else do we need to move forward? Do we need more information? Do we create a business case, etc?

A great question asked was “what if I work for the company hired to build speed bumps?” Kent responded that you should still go through this process. It’s a hard pill to swallow, but you need to focus on the right solution, not just building a solution.

There was much more, but I ran to another session.

To contact Heather – [email protected]
For more about Kent – https://www.kbp.media/

Joshua Kerievsky and Heidi Helfand – High Performance via Psychological Safety

You may have heard of Joshua. He was the one that introduced me to Modern Agile. If you have not looked into Modern Agile yet, you need to. One of the principles of Modern Agile is Making Safety a Prerequisite. It was no surprise they were talking about Psychological Safety. For this talk they focused on the impact of conflicts in organizations. A quote they shared the book Crucial Conversations summed it up. “The health of an organization is measured by the lag time between when you feel it and discuss it.” Healthy organizations address conflict closer to in the moment than not. The longer you wait to address conflict the faster trust breaks down.

They gave the attendees an approach or mechanism to conflict resolution. To help have that critical conversation and reduce emotion an approach called C.O.I.N. is a great technique. Each letter represents a part of the conversation.

  1. Context – What are the facts of the context…what happened?
  2. Observation – What did you observe?
  3. Impact – The impact of the conflict on you or others.
  4. Next Time – What can we do next time to avoid conflicts like this?

Some may be thinking, why is conflict resolution so important at an agile conference. I think these types of sessions are critical. Agile teams get put together and not enough time is spent on how to interact with each other.

For more about Heidi – http://www.heidihelfand.com/
For more about Joshua – https://www.industriallogic.com/people/joshua

Kupe 08092017 2Me – A Conversation about Connecting and Building Relationships

My session was not a presentation, rather a conversation with the attendees. I had a great facilitator, Curtis Michelson. Here is the premise of my views on the need for all of us to do a better job connecting with others and build trusting relationships.

It’s 2017 and we are deep in the age of robots taking over ordinary jobs. This leaves us humans to focus on work that has us working with robots and yes, humans. The World Economic Forum lists the top 10 skills we’ll need by 2020. Seven of the 10 include direct human interaction.

They include Creativity, People Management, and Coordinating with Others, Emotional Intelligence, Judgement and Decision Making, Service Orientation, and Negotiation. Even if robots are not completely taking over there is still reason to have a clear focus on building your people network and building strong, trusting relationships.

In today’s environment, we need to move quickly. When you are working on an initiative, you need to know who the go to people are. You need to be able to access to them. Just think about your day. You most likely don’t have enough time to do everything you need to do. You don’t have enough time to meet with everyone that needs to meet with you. How do you prioritize who you will talk with? Most likely one factor is people you have a relationship with already. You are not paid for what you know; you are paid for who you know. Information is plentiful today. In a few clicks, we can get answers to almost anything. Begin to take pride in getting the right answers to everything, not having the answer to everything.

This means you need to take an uncommon approach to connecting with others. You need to step up your game if you are going to add value today and be ready for 2020 and beyond.

My goal in life is to meet everyone in the world. So, please connect with me on LinkedIn.
For more info about me – www.kupetalks.com

Permission, Trust and Safety – Tim Ottinger and Ashley Johnson

I decided to stick with the softer side and went to see Tim and Ashley talk about Permission, Trust and Safety. Now that I look back, most of the talk was about Trust and Safety. I can’t recall what was said, if anything about Permission.

Most of this session was the attendees talking through what teams look like when there is safety and trust. And what it looks like when there is no safety and trust. In Summary, Tim and Ashely defined trust as the firm belief in the reliability, truth, ability, or strength of someone or something. Someone says they will do something and you believe that to be true. The summary of the safety definition is team members feel accepted and respected.

A big win for me was the discussion on responsibility. That we must take responsibility for our actions and that includes being intentional about earning trust and providing safety. They covered some work done by Chris Avery and studies on the things we do before taking responsibility. When something goes wrong – we do the following instead of taking responsibility.

  1. We look for someone or something to blame
  2. Justify – We make up stories
  3. Shame – We fall on the sword and shame ourselves in hopes that everyone feels bad for us.

The key is trust and safety is a prerequisite for successful teams.

Day 2 was awesome. I had the chance to connect with others and learn a ton. Day 3 starts soon!


Advertisement

AGILE 2017: KUPE’S VIEW – DAY 1

Orlando, Florida, August 7, 2017: Agile2017 started off strong. If you have never been to Agile Alliance’s major conference, it is one of those conferences that has something for everyone. The conference Chair, Tricia Broderick, kicked things off at 9 am giving everyone, all 2,500 of us, the lay of the land. Since many of you could not be here, I wanted to write daily posts sharing some highlights. I hope you enjoy my daily recaps.

First up for the day was they keynote speaker, David Marquet.

David Marquet – Creating Leadership and Engagement at Every Level

David was the Captain of the USS Santa Fe, a nuclear submarine. This is where he really learned about leadership. His message was clear from the beginning, “Leadership is not for the few at the top.” He went on to talk about how business value creation and business differentiation depends more on people thinking and making decisions over execution and process discipline.

That is not to say execution and process is not important. You do need to get things done. The challenge is there is more doing than thinking in many organizations. David, said this gets people killed in the Navy. For most of you, no one may die, but money and time is wasted.

He explained this by showing the old way of leadership being 3 steps.

  1. Intent – The leadership defines the intent or the mission. (Thinking)
  2. Debrief – The intent is shared with everyone. This is your time to ask questions. (Some Thinking)
  3. Do – Everyone does their job.

In the doing mode, people look to leader to make decisions. David explained at a time, leaders where taught to know everything about the space they lead. In the Navy, if you were going to command a submarine, you went to school for a year learning every aspect of the submarine. You knew the vessel inside and out. So, if something happened, you could make a decision on what to do.

This is a flawed model. Leaders can not know everything about everything. Leaders today need to allow their teams to think and react based on what is happening in the moment and not rely on the leader at the top to make all the decisions. He summed up this concept by saying leaders need to help their teams prepare to win. Then when doing the work, give them the control. This image he shared sums up the concept. You give your team members more control by giving them the ability to their job and clarity of the goals.

Kupe 08082017 1

 

There was so much important information shared it’s hard to sum up his talk. But, I will try anyway with something he said. It is not about leaders making better decisions. It’s about making everyone better at decision making.

For more information, you can visit http://www.davidmarquet.com/

A Conversation with Ron Jeffries & Chet Hendrickson

If you don’t know these guys, you need to. These guys have been around before the beginning of Agile. Ron is a founder and was one of the few who created the Agile Manifesto. This session followed a Q&A format. Here is a highlight of their responses to some good questions about agile.

Ron was asked what he would change in the Agile Manifesto now that he knows more. Ron stated that he would not change anything. It was thoughts from a group of mostly like-minded people at a point in time. He did say he would push for a more diverse group. He did add that he would try to clarify language, especially the use of the word ‘over’. One of the values is “Working software over comprehensive documentation”.

The word ‘over’ was interpreted to mean, we don’t value it. So, everything on the left side was valuable and everything on the right was not valuable. He wishes they gave more clarity around that word. Chet added the true meaning is we put more emphasis on the left side. The right side is still needed.

Another question started a conversation around scaling agile. It was clear Rona and Chet are not big fans of sticking to set processes for agile teams. My sense was they feel things like SAFe and Scrum have been misused to allow management to control their teams.

One of the key takeaways from this conversation was to not make teams all do the same thing and follow the same exact process. When companies think of scaling they feel each team should follow the same process. Ron and Chet believe it is best to allow each team to act like they want. The one consistent thing is to focus on the outcome. If the team is delivering software and customers are happy, let them do what they do.

The last point I’ll share from Ron and Chet is their belief in team diversity. They feel teams need to be diverse. Have diverse skills, ideas, and behavior styles. That is how things get done. Ron shared this was something he learned over time. In the past, he would hire people just like him. That doesn’t work.

For more about Ron – http://ronjeffries.com/about.html
For more about Chet – http://www.hendricksonxp.com/


Kupe 08082017 4

Steve Denning

After lunch, I had the pleasure of sitting in a session with Steve Denning. He is a business pioneer and an author of six successful business books and a former director of the World Bank. There is more to his history, but I think that shows that he is the real deal.

Denning is a big believer that agile is a mindset, and it needs to be embraced throughout organizations and not just in software development teams.

He touched on three laws that will help teams and organization achieve and maintain agility.

  • The law of the customer: An obsession with delighting customers by continuously adding value for customers and users, as well as a recognition of the current need to generate instant, intimate, frictionless value at scale.
  • The law of the small team: A presumption that in a volatile, complex, uncertain and ambiguous world, work needs to be disaggregated into small batches and performed by small cross-functional autonomous teams, working iteratively in short cycles in a state of flow, with fast feedback from customers and end-users.
  • The law of the network: The entire firm functions as a fluid interactive network, not merely a top-down bureaucracy with a few teams implementing Agile tools and processes.

The third law is my favorite, since I am speaking about the value of your personal network on Tuesday. Denning uses the word adhocracies as the opposite of bureaucracies. Adhocracies are flatter organizations. By having the interactive network anyone can be connected with anyone. Anyone can get information needed from anyone. There are no prescribed channels to go through.

One of the greatest lessons from Steve Denning was to always be learning. He has written six books and has over 600 articles published. He is a smart, thoughtful man. A person this accomplished still says he is learning and adopting his thoughts every day.

For more on Steve Denning – http://www.stevedenning.com/site/Default.aspx

Angie Doyle and Talia Lancaster – Sketching outside the box: Visual Thinking for Teams

Kupe 08082017 3

This was the fastest 75 minutes of the day. Why? Because it was like we were in art class. Angie and Talia taught us how to use visuals to help when facilitating sessions or taking personal notes. Why draw and not just write down bulleted lists? Here is what they shared:

  1. Drawing helps see the big picture. Pictures tell us so much more than words.
  2. Drawing heightens engagement. People are more engaged in a conversation when someone is up drawing.
  3. Science shows that it helps you think strategically, tactically, and creatively.
  4. It helps you get on the same page faster. Maybe you can have faster meetings.
  5. It addresses all learning styles. Reading, visual, auditory, and tactile.
  6. A creative way to record a conversation. Pictures help more with recall.

Many people in the session were not artists. That was OK because Angie and Talia did a fabulous job teaching us simple tips to get started. Like most things in life, it takes practice to get better. This is one of the things we should all practice more.

To help show us that we could all do it, they lead us through a visual jam. Angie gave us 6 words and we had 30 seconds to draw something that represented each word. In 2.5 minutes, here is what I drew. Can you guess the words? By the way, no judging my lack of artistic ability!

Kupe 08082017 2

You can tweet Angie and Talia – @Doyle_Angie & @SketchingSM

I am off to day 2.

All the best,
Kupe