Sarah: “Walter, I just want to check in with you following the team demonstration and see how you are doing with the new Agile approach”
Walter: “Sarah the results were thrilling for the customer and the team. Everyone seemed engaged and the dialogue was very healthy. I see it, but it does not make sense. We are moving features through the team faster, but I had to do this with dedicated resources. I am sure this is costing me more.” Sarah: “Walter, this is totally normal. You are seeing the difference between single tasking and multi-tasking as well as optimizing the whole versus a certain roles or steps. We can do a little model to show you that this Agile approach is better, faster and cheaper.” Walter: “Well that would be very good because it is very counter-intuitive to me and all my management tools and tricks seem to run at odds with this approach.”
Sarah: “Great observation, Walter! As you told me earlier, you tend to focus on fully allocating engineers. In Agile we focus on increasing the throughput of value by optimizing the whole flow through all roles.”
Walter: “Right now I just want to stay out of the way, because I do not know how to help.”
Sarah: “Walter, let’s spend some time to get you comfortable with the impacts of batching, queuing and task switching. Once you see the math, we can talk about how to serve the team by proactively clearing impediments to smooth flow and taking some savings to invest more in them. The team will love you for this commitment.”
What benefits will you see when teams are in Flow?
As we described in “What so Great about Flow?“, we think of attaining Flow as the first step in our recommended approach to enterprise Agile adoption. For this step, we focus groups on adopting agile by the book by team; thus the impact from Flow is only incremental and isolated to the specific team. However, this does not mean the results of this effort are not noticeable and infectious.
Foremost, groups that attain Flow make changes on the way to becoming a team. When given space and dedicated members and short time box, new agile teams take three key steps:
First the collection of individual contributors comes together to plan a limited portion of their own work.
Second they set norms and limits that lead to common commitment to deliver working, tested increment.
Finally, they open their increment up to feedback and open themselves and their process up to feedback, introspection and adjustments for continuous improvement.
The benefits seen from doing this are many:
A team is forming and that makes work more fun and easier for them to manage
Work-in-process is getting reduced by focusing the work on a small increment of functionality
Testing is coming forward in the process and quality is beginning to become a team issue
Hand-offs and delays are declining by dedicating a cross-functional team to working on one thing at a time
Feedback loops are shortening in the demonstration and review process helping to prioritize the next step
Typically these benefits take one to three iterations to manifest themselves and translate into incremental productivity increases of 15%, 25% faster cycles and a reduction in downstream defects (See the Agile Impact report for more details of business improvements from Agile). Most of these teams are reporting the benefits of flow. Teams in Flow settle into a predicable pattern of delivery. They are not perfect, but you can count on them and estimate based on their historical velocity. We look for these metrics to know if a team is in the state of Flow including:
a rate of 90% or greater of Story Acceptance per Iteration on an iteration over iteration basis
an average of zero net, new Defects added to Defect list across iterations
A reduction in 1/2 of the amount of stories that are in-process across iterations
A continuous build success rate of 90% or greater for the team’s isolated code base
In general, they are starting to do things in a more lean and less wasteful way. By working together on a small batch of work with a clear definition of done, it allows the team to focus and reduce the task switching. To understand why multi-tasking and task switching do not work, you should read this post from Mark McGuinness at Lateral Action or check out Tom Demarco’sbook “Slack” and specifically pages 16-21.
However, the most important benefit is the positive feedback from the team members with regard to forming a team and working in this intuitive and social approach. It is this positive feeling that propels teams to move past Flow and into Pull. Congratulations if you have the continuous improvement snowball beginning to roll downhill at your organization. Building the trust and capabilities of the team is the most effective path to more value delivery. (See “The Scrum Picture is wrong” and the comment/link about the Lean Journey from Jason Yip.)
If your team does not find this benefit, it is clear that there is a fundamental issue that needs to be resolved. This is a great time to bring in an outside coach to help the team retrospect and give them space to form. In these situations, it is easy overlook the fact that teams need to go through the process of of forming, norming, storming as they reach toward performing. Remember this is a journey and you can not go there without building the team.
Walter: “So Sarah, I am trying to get started with this Agile stuff.” Sarah: “Great, I am here to help. What have you done so far?”
Walter: “Well, I get that we deliver something every two weeks. Agile makes us hyper-productive. And to do that, my job is to make sure everyone is busy all the time, right? We’ll get the most features if I get people to sign up for the maximum amount of work at the start of the two weeks. This is easy!”
Sarah: “Hmm, I think we better take a step back. You may be misunderstanding something about productivity. Have you ever heard about Slack or Done or Flow?”
Walter: “You mean like Slackers who just blow off work? Sure! And done means its coded, right? And Flow must have something to do with how you hide under the radar to get away with slacking how much you code. Gee, this Agile stuff doesn’t sound very productive after all!”
Sarah: “Well, Walter, I think we need to have a long talk. Coffee or martinis? Pick your poison.”
So What’s so great about Flow?
Walter is stumbling on how to get his teams started with Agile. He holds the notion that it is HIS job to make sure everyone is fully allocated, super-productive. And for him, productivity is measured in lots of features coded.
Sarah has some great advice here guided by the Lean principle of Flow. Productivity is not about filling our plates to maximum capacity during planning meetings. Rather, we encourage team members to build in “slack” in their commitments. They seek Flow of value delivery versus 100% allocation. That is: “Of our total time at work in this 2 weeks, we really only have this much time available (e.g. X hours). And because we need to allow room for discovering what we can’t know, we are only going to sign up for and commit to this much (e.g. 80% of X) work.” As for “done”, a team commits to a certain, attainable level of doneness that includes more than code: testing, documentation, code review, acceptance, etc.
When teams pull these two fundamental Agile practices together, they are invoking the Lean Principle of Flow as guidance.
This is important to understand. Agile teams paying attention to Flow do not bloat estimates in order to manage uncertainty. Nor do they use bloated estimates to artificially create 100% allocation within a timebox. Rather, teams give their most accurate estimates for the work. These estimates include what work it will take to adhere to their definition of “done”. Embedding slack in team capacity absorbs the uncertainty and doubt incumbent in new work. And, at the end of the timebox, a team truly committed to Flow checks in on how it delivered value. It then inspects and adapts how it can continue this smooth value delivery.
Sarah, gets this. New Agile teams that concentrate on Flow before moving to other rigors create a sturdy foundation for continuous improvement.
To be clear, here is what we mean by Flow.
A team commits to only taking on as much work as they can deliver consistently over time. Think of Flow as the work that can smoothly move through a pipe that delivers value to customers. If we fill the pipe to 100% capacity (as Walter is eager to do), we create at the very least turbulence. At its worst, value delivery stops entirely. When Flow becomes this turbulent, work becomes sloppy and quality suffers.
So how can you tell if your team has embraced Flow?
There are a few basic tell-tale practices you should see. Teams in Flow:
Are empowered and collaborative in decision making
Don’t over commit to what they can deliver
Declare a definition of “done” for how they make commitments to value delivery
Use a time-boxed rhythm with slack for high-quality product delivery
Engage in inspection and adaption practices that amplify their learning about team agreements, process and their definition of “done”
Most importantly, teams in Flow have a smooth reliable rhythm of delivery. They can be seen making and meeting their iteration commitments and thus have a stable iterative and incremental process. This is the key first stepping stone to Agile adoption.
Sarah will stick with Walter and his team in their adoption of these Agile practices of Flow. She’ll check in with them for a couple of iterations to help them inspect and adapt while adhering to Flow. Sarah knows there are tons of quick wins to find when teams move to true Flow. And she’ll be there to guide Walter and his team even when the roadblocks to those wins seem insurmountable.
About the Author: Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
We’ve been blogging on many Agile topics over the last few months - initial Agile adoption, culture shifts, organizational change, product ownership and project management, among others. These topics, for us, often conjure up images of the people who read our blog. Some readers might be in a more traditional camp of software development and a bit skeptical of Agile. Others may be “biting at the bit,” as it were, to adopt Agile or to keep their Agile practices ever-maturing.
Enter our new Agile Blog buddies, Walter Fall and Sarah Scrum. We bet you know someone like these two readers.
Who is Walter Fall?
Walter is well-meaning but may be just a bit stuck in an old school way of doing things (The guy still carries a comb just for his mustache for goodness sake!). He holds fast to the practices he has accumulated over the years and is happy with where his career has taken him. Walter has been with his company for 20 proud years and now runs a division of ~120 people, all organized in functional teams. Walter’s VP, a golf buddy, recently brought in a full-time consultant named Sarah Scrum to coach him and his group on adopting Agile practices. Walter is unamused, but he’s willing to listen, if only to prove her wrong.
Who is Sarah Scrum?
Sarah is passionate about Agile. She seeks continuous improvement, almost annoyingly so. She loves a challenge and has found Agile to be a valuable resource for tackling technical and organizational challenges. Sarah has worked with Agile teams for the last 7 years leading them through maturing and scaling their Agile adoptions. Her goal with any team is to teach them to fish as fast as possible. And at times, she may be just a bit impatient and come across as not based in the real world. She has just been hired to be an embedded coach for Walter Fall. Given what she has heard about Walter, this should be an interesting time!
Now that you’ve met Walter and Sarah – Who do they remind you of?
Your Boss? Someone at your last job? You at your current job? Certainly, this is not about good versus evil. Both Walter and Sarah can learn from one another in terms of best practices and adoption paths; the realities of large scale adoption; the pain of moving from one’s comfort zone; and, the thrill of enabling teams to continually find pride in their work. And you can bet they will challenge one another.
Look for Walter and Sarah to pop up from time to time on our blog with their perspectives. We hope their interactions prove to be both fun and informative as you follow the progression of their Agile story.
About the Author: Jean Tabakais a wine enthusiast, an Author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts. That question is quickly followed by, “And I don’t want to hear that it works everywhere!”
Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”
Where To Start
Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.
Our rendition from "Stand Back and Deliver"
In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts. They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed. The variables used in the book include:
Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies
Three Perspectives
We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project. The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
Projects of Low Uncertainty and Low Complexity rank third. They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.
Environmental Factors
Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success. Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments. Here is a snippet of that kind of team assessment:
Does the Product Owner have the right level of authority and influence? Are they…
Embedded with team?
Dedicated to the project?
Able to gain consensus from stakeholders on goals and features?
Able to evolve the product backlog (with training)?
Able to support the team through constant feedback and decision-making?
The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
Architects might be contributing members, or might be advisory.
Is the team co-located?
It’s not required, but can be a risk factor.
For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.
Do you have an Uber Product Owner and Uber ScrumMaster?
For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.
Is there a controlled build environment?
To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).
You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach. To me, Agile works everywhere, it is just a question of how good do you want to be and by when.
I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what succeeds versus falls back, I do not believe there is a “cookbook” for Agile adoption. Of course, the question then becomes:
If there is no cookbook, then what is the best approach to succeed with my Agile adoption?
Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.
The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking. However, Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations. In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.
Getting Over the Hump - Critical Step #3
Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)
We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.
What do you think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?
“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.”-W. Somerset Maugham (1874 – 1965)
Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.
Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey. It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.
Don’t pass up this great opportunity to learn from the experiences of others!
RallyDev.com
