Hello, I’m Veronica
The sky is not completely dark at night. Were the sky absolutely dark, one would not be able to see the silhouette of an object against the sky.
-
Becoming Agile Without Help?
I was recently asked how successful can organizations be in transitioning to agile on their own. My immediate response was to evoke the response from a team of
panelist. When asked what is the most important thing they did to be successful in their transition, four panelists from across industries and organizational sizes all said essentially, “Getting some good help.” I’ve been pondering this question for the last couple days. I’m sure it is possible to self-transition, but I’ve never seen it done. I’ve seen new teams start out promoting agile, but in practice employ cowboy coding. I’ve seen teams implement agile tools and use them only to track the completeness of feature requests. I’ve seen teams take over agile practices from a third party and start out using agile well, but drift away from it as they short circuited fundamental principles that were not well engrained or fully understood. I’ve heard tech leads discuss how they tried using agile after some research and found it did not work well in their organization. I know I did it wrong before getting training and having more than a few learning cycles under my belt.
I tried searching Google and a number of blogs last evening to see if I could find any references to no-help, self-done, successful agile transitions. I couldn’t find any. Now, you say “sure, the pundits are in the business of helping others.” But I expected to find at least a few contrairian posts. Nope. Either I’m not searching well, or it is indeed rare.
The best result from this quest was a quote from a presentation by Clarke Ching at Scottland IS that listed this as a reason for agile failing: “Trying to transition to agile without help OR outsourcing the transition entirely to ‘experts’.”
The second part, I agree with. You cannot be successful by hiring someone to make you agile. It takes action on the part of the those that will execute the new process. It needs to be practiced. It needs to be refined through retrospection. And, perhaps the best reason why outside help is so common, is that it needs to be internalized – not just by a champion, but by everyone that will be using it. Building that kind of organizational wisdom in short order (before the initiative fails) is perhaps near impossible.
I’d love to hear examples of where it’s been done without outside education, guidance or coaching. Please leave a comment if your organization has been successful, you know someone, or know someone who knows someone that’s done it on their own. I know at least the first team did it without help. Let’s find others.
-
Fail Early, Learn Often
While moderating a panel discussion recently, one of the first questions after the introductions was asking to explain what was meant by allowing a team to fail. The important understanding that I think was misunderstood is that failure is not meant to allow releases or products to fail, but to generate learning opportunities to ensure ultimate success.
Saving a company is an extreme example of what learning often is trying to avoid. Roger Ehernberg has a thoughtful post describing the lessons learned from the recent closure of his company, Monitor 110. In it, he acknowledges his failure to fail as a major contributing factor to the company’s downfall:
We talked about “release early/release often,” but were scared of looking like idiots in front of major Wall Street and hedge fund clients. Is it better to wait a bit before releasing to have a more compelling product or to begin getting feedback on a less impressive offering? We chose #1; in retrospect I think we should have chosen #2. By choosing to wait we lost our intimacy with the customer falling into the classic trap of pursuing a “science project,” not building a commercially salable product. Dumb.
We should have gotten it out there, been kicked in the head by tough customers, and iterated like crazy to address their needs. Woulda, shoulda, coulda. Didn’t.
Don’t wait until you’re writing the post-mortem on your defunct company /product/ team/ release to realize the power of early failures. In contrast, Dean Leffingwell advocates the “fail soft” option:
Agile master Alex Yakima once commented while looking at an upcoming release plan and the few remaining iterations, “nope, not enough times to fail.“ So we shortened the iterations and made the release on time.
Creating opportunities to fail allows people, teams and organizations to speculate, explore and adapt while they can still make adjustments that lead to ultimate success.
-
Measuring Outputs Expanded
I talked at a high level in my Measure Outputs post about the types of measures that are useful. That post stated broadly that input measures do little to help improve, control or predict performance. In this post, I will expand on that concept to cover in more depth what types of measures focus on output and help drive process improvement.Perhaps the best known framework for creating measures is the balanced score card. This sets up categories of metrics that support
an organizations strategies and vision. From the Balanced Score Card Institute, this framework is shown to the right. I find it useful to apply it to business processes as well as overall strategy. Even though processes are just one component of the model, they ultimately support part of a business’ strategy. A framework helps to ensure we considering measures that contribute to the overall strategies and goals the process supports.Once a framework is chosen, the next thing to consider is the customers and stakeholders that the process serves and what they value. This identification is important to ensure we know the objectives that the process is to support. If the stakeholders or customers tell us they want high performance, personalized, niche process (a BMW) the measures will be different than if they want a quality, efficient, repeatable process (a Toyota.)
The next question is what measures are valuable. I continue to see the same types of measures used across process improvement projects. For each category of the framework, there are common recurring measures that are useful:
Process: There are three key measures that are critical to almost all processes: Productivity, Quality and Cycle Time.
Productivity: Always measured as Output / Input. I once saw a company that measured productivity as the % of time spent on coding. I get the thought, but it is only half the equation and, frankly, the less important half.
Output: Products, features, backlog or other work units should have standard “story point” or relative size estimates assigned. This normalizes the output across different work effort or output value. It also helps to facilitate planning so that resources can be assigned to work based on size and with pricing so that appropriate prices are assigned per output unit.
Input: Measures the capacity of available resources used to create the outputs. Be comprehensive and don’t give resources credit for working off task. If you are paying
for the resources, they should count against output even if not always focused directly on it. Also, you should be able to factor out overtime from this component of the measure as it is not sustainable capacity.In Agile development, Velocity or BurnDown is a Productivity measure. You may say it only shows output, but since capacity is held steady by a dedicated team, only the output need be measured.
Quality: Repeat after me… “Never use defects found as a quality measure.” You want to find defects. The way to find them is to ensure quality is built-in through proactive testing. The output measure for quality is the testing done to support acceptance.
Tests planned, run and passed is a proactive measure that attempts to ensure that the quality of a process is planned and built into the delivery. The testing process defines acceptance criteria and should be built into construction of deliverables and happen at various stages with the earliest coming during early requirements and build. The only rules here are from test driven development: the test should only test one criteria, it should only fail for that criteria, and it should be the only test that fails for that criteria.
OK, one exception to the mantra: Measure defects found by the customer. Track these with a vengeance and apply process and measures to them to ensure they are adequately corrected and customers stay satisfied.
Cycle Time: Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time and time spent waiting to take the next action. It is a measure of time from request to delivery or concept to cash. It includes not just how fast
development happens, but the time it takes to capture, prioritize, design, develop, test and deploy functionality and all the time in between. Ensure your cycle time measure is expansive or you will sub-optimize the overall process. Also, realize that not all requests are created equally. Ensure those that have the most value get priority treatment. The features in your backlog that are low priority may deserve to grow old on the backlog and eventually drop off. Or perhaps there is value in tracking cycle time for bug fixes vs enhancements vs new features.As long as your prioritization process is fast and exiting the backlog requires deployment, the average age your backlog is an easy proxy for cycle time.
My First Law of Development is about maximizing productivity while minimizing cycle time if you’d like a deeper read.
Some organizations use On-time Delivery as a proxy for cycle time. While this is an OK measure for customer satisfaction, it does little to report the health of a process. If important to your customers, use it as a customer measure, but also use cycle time as a process measure.
Customer: Often, quality is used as a proxy for customer measures. This can have the unintended effect of missing other critical voice of customer measures. The best way to
ensure the customer is satisfied, is to ask them. Simple surveys or votes are perhaps the best way to capture this measure. Ask customers about what is important to them. There are many online survey tools that will allow you to ask relevant questions from your customers and track trends over time. Or, use a net promptor score by simply asking “How likely are you to recommend our product / service.”Mike Griffiths has an eloquent sponsor/ customer tracking approach that asks for a vote of confidence or satisfaction. In aggregate, this provides a customer-focused index over time. I also like the emoticons in his customer chart.
Learning: Learning should measure the
capabilities of the team members. A matrix of who can use what tools and develop what products or product components with a level of expertise assigned is a good starting point for tracking this measure.
% coverage becomes a good aggregation of this measure. Be sure to include current skills as well as upcoming skills and both soft and hard skills in the matrix.
(From The Lean Six Sigma Pocket Toolbook: A Quick Reference Guide to 100 Tools for Improving Quality and Speed, Mike George, et al)Financial: As high-level financial measures go, I have a pre-disposition to ROIC. It balances profitability with the investment costs required to generate it – and is a topic for another post. Most processes will not require this comprehensive of a measure, so simple cost tracking usually suffices. This can usually be further simplified to time tracking since development is largely made up of salary costs. Make sure you at least consider equipment and other capital and marketing costs before you settle in on time tracking as your financial measure. Normalizing financial tracking to earned value or planned spend helps to show tolerances of spend on a project (and display productivity with the financial measures.)
PS: I have intentionally tried to make this post very visual. The key to making measures useful is to make them easily understood and highly visible and public.
-
Team Charters
When launching any improvement initiative, the first step is typically forming a team that can get down to the work of getting the job done. To get things off on the right step, I cannot emphasize enough the importance of a team charter. This is true for new agile teams, quality teams and any improvement initiatives when more than one person is needed to get results.
Why, because creating a charter makes sure that proper thought is devoted to the define the problem, set goals, scope and approach, and identify the people and other resources that are necessary to be successful. This simple step forces initial action that sets teams up for long term success.
The format for a charter should be quite simple. Typically, they are written with the following headings:
- Team Name
- Problem Statement/Business Case (why team created)
- Scope (what will and will not be addressed by team)
- Team’s Customers and their needs (how will the team define success)
- Team Leader (& champion/sponsor if different, & governance if needed)
- Team Members (with expertise and time commitments for each)
- Specific Objectives and How Measured (updated monthly or quarterly)
- How you will work together (methods, meetings, norms, expectations, guiding principles)
- Plan (initial team duration, activity backlog/tasks, milestones, meeting schedule, stakeholders and communication expectations – updated as needed)
- Resource needs (other people, budget, tools, etc.)
The charter creation process should start by having sponsors designate an initial team for the initiative. This team builds each of the above bullet points collaboratively and works with the sponsor and others as needed to gain agreement. Having a team charter at the end of this exercise documents and communicates a team’s purpose. More importantly, the process of creating and maintaining the charter builds understanding of and broad commitment to that purpose.
-
Why Sign on the Dotted Line
Consulting organizations often require signoff on deliverables to ensure that the client acknowledges that contractual obligations are met. Across organizational lines, these signatures, serve mostly a legal purpose. I often wondered about the use of signoff on deliverables inside of an organization where there is no external relationship. I’ve seen some development shops average as many as 15 or 20 of these sign-offs a day.The intent of getting signatures on product deliverables, of course, is to ensure that the proper attention was given to the creation of the product. The cynic in me says it is to fix blame. In reality, I believe it points to a need to compensate for poor collaboration and broken processes. Once the decision has passed on whether to create the product or deliverable and allocate resources, forcing signatures at various check points in a process serves as an attempt to ensure everyone is kept informed and had an opportunity to participate. Of course, the problem with this is that at the point of sign-off, the ability to give meaningful input that can help formulate an improved solution is usually past. Unless those on the signature line are involved when needed in the discussions and decisions that get built, the signoff sheet at the end of the creation is likely to only be only a rubber stamping exercise.
What is a better solution? Ensure stakeholders get involved in the decision of whether or not a deliverable is of high enough priority to start. Once that decision is made, create a process that demands collaboration. Make one person (the product owner) responsible for representing and getting input across as many interests as they can understand. Involve those on the signature lines in planning and closeout sessions on a set basis where they can see the product or deliverables as they are built. If some input is of limited nature, start with that at these meetings or have the product owner represent the interest. Ensure the collaboration continues between these formalized checkpoints as well. By focusing on a collaborative process, everyone’s input can have a positive impact on the fit and quality of the product as it is created.
If your organization is signoff heavy, it’s probably time to find out what systemic problems need fixed.
About Me
The sky is not completely dark at night. Were the sky absolutely dark, one would not be able to see the silhouette of an object against the sky.
Follow Me On
Subscribe To My Newsletter
Subscribe for new travel stories and exclusive content.
Horizon Line Group 