Agile Development Blog

Right now, I’m watching a company try to improve itself.

It seems that management has recently learned that there is a thing called Lean, which even comes with some cookbook recipes called practices that you can do. There is lots of nifty new lingo, and it’s complex enough that you can interpret it nearly any way you choose

ShuHaRi - stages of learning that lead to mastery

This company has reason to believe that they have some understanding of this new animal because they feel that they’re already Agile, but as far as I’ve been able to determine there is nobody involved who has, lets say, an actual resume chock full of actual training and experience in Lean. The employees are pro Lean because (a) they always validate what management wants, (b) they want it, too, and (c) they think they understand it.

And I find myself thinking, “This is not right. You are doing these practices in ways that I have never seen discussed in any of the books or courses with which I am familiar, and I have put in some time studying this stuff. You are tossing ideas around like you really understand them, and I do not think that you do. Worse, you’re starting out with complex new ways of doing it rather than start at the rock bottom with the basics. This is bad!”

Then I have an opposite thought, which is something like, “Hey. What are they supposed to do, sit around reading books for five years before they try something? That’s just another form of analysis paralysis. Go for it!”

Then my coach brain kicks in (by now I can feel my brain cell overheating, but I persevere), asking me -  How may DIY (Do-It-Yourself) Agile implementations have you seen? (Answer: A lot) How many had great results? (Answer: Few) How many sucked? (Answer: Most) I am suspicious of DIY Agile and DIY Lean because I have seen too much badness there.

Enter Shu, Ha, Ri – a concept first introduced to the Agile world by Alistair Cockburn. The phrase is used to describe the three stages one goes through when pursuing the mastery of a complex art.

Shu, the beginner stage, is where you know nothing and you limit yourself to a rote application of very simple practices.

Eventually you reach the Ha stage, where you can stop concentrating on the simple application of techniques and graduate to the skillful execution of complex techniques that follow the known rules of your discipline while handling exceptions and even new situations.

Then, and only then, can you aspire to Ri, which is where you forget everything you know because you are beyond thinking about it. Here you transcend rules and blend techniques in artful and unpredictable, yet “correct” ways. (For me, this is the stage where “you can do it drunk”, though others may choose to describe it differently).

So returning to our story – here is the behavior I’d like to see from this company.

I want the company to reach and stretch, but I also want them to do it right. I want them to have a realistic understanding of who they are, and at the same time, not allow that understanding to deter or slow them down. How would that be possible? There’s only one answer that I can get to, and it is that you have to both act and study if you’re going to do either one effectively. Go ahead and leap right in, grab the marmoset by the tail and go for it, just don’t forget to do your homework too.

If I could talk to the management of that company, I’d urge them to get expert training for their people and to slowly, methodically, and gently yet firmly allow the company to move in the new direction. And I’d want them to make sure they are getting it right. It’s too easy to make this stuff up, and it’s too easy to bulldoze employees into following you down a path. Who’s going to argue with the CTO or the CIO or the CEO? Not many people will do that.

So I say, be humble. Bring in the consultants. Get the training. Keep trying new things. Be open to failure and to admitting wrong-headedness. You’ll make it. Just be balanced in the learning and the doing.

That’s what I think, anyway.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Last Thursday, Ben Carey kicked-off our latest and largest webinar on the topic “How Teams Succeed with Agile Quality and Testing.”

Thank you everyone for the great compliments; a majority of the compliments should go to Ben, Jessica, Bob and the folks from SQE for the quality effort.  Thanks to these great folks, it was technically perfect, visually pleasing, entertaining, impacting and backed up by great supporting content.  If you missed it, you can see the video reply to this webinar.  You can find the supporting content under the Learn Agile part of the Rally web site.

Following that webinar, I saw a twitter post from one of our customers about the meeting they had following our webinar. This “Lunch and Learn” session allowed the team to reflect on what the heard immediately following the webinar.

“Having a post-webinar discussion with our SQA group on the #rallydev seminar. Nicely done @RallyOn & @BenCarey”

This is a great example of self educating on this topic.  It is the first of four steps that we recommend in the webinar:

1. Self-educate and discuss to set the context
2. Find an external driver for your change to keep from having drifting goals (customer, competitor, benchmark)
3. Make a commitment as a team to move forward
4. Find your first practice to adjust and adjust just that one only

If you liked the webinar and content, I encourage you to set up a lunch and learn to view and discus these topics on your team or program.  If you are interested in more depth, you might consider our next webinar in the series, Pulling Quality Forward: Agile Testing and Tooling for Embedded Software Development. The live presentation will take place on Wednesday, September 30th at Noon MDT with Zach Nies, VP of Product Development at Rally and Paul Henderson from WindRiver/Intel .  You can register on-line and learn more about the details.

I have found the quality topic to be great for team lunches.  It is can be a sticking point especially for functionally divided teams and quality has to be owned by the whole team.  I encourage you to take advantage of either of these webinars to hold a “lunch and learn” topic for your team. Maybe after your next demo and before your next retrospective.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

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 Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or 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 Tabaka is a wine enthusiast, an Author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

It has come to my attention that there are two software development approaches hanging around the water cooler these days, one of which is inaptly yclept (I’ve been waiting most of my life to use that phrase!).

The first approach is called Waterfall and the other, called Agile, has a name that I think is all wrong. If Agile is the opposite of Waterfall, then I think it should be called Pond. Yes, Pond. To understand why, let’s first think about what a Waterfall project is like:

In this metaphor, the Waterfall project will be represented by the activity of riding a boat over a … do I see any hands? … no?… ok then, I’ll tell you … A waterfall.

So what is this ride down the waterfall like?

Well, it starts off very exciting. You get in the boat and head toward the waterfall. There’s never any question of where the waterfall is, you just go the way everybody else is pointing. It starts off kind of fast, but it’s a fun kind of fast and everybody in the boat is up for the challenge. Then, as the current gets going to about 40 miles an hour, you decide to change direction. Well, that doesn’t go so well, does it? Zooooop, and you’re over the falls just like that. Waterfalls are not about change.

On the way down (where we’re doing our project in this metaphor) there is lots of noise in the boat. People are screaming at one another but it doesn’t make any difference. Nobody is doing what they said they’d do back when the trip was planned, and nothing anybody tries makes a difference in the direction or stability of the boat. There is steam and a loud crashing noise coming from the bottom of the waterfall, but nobody can accurately see what’s below. Nobody is entirely sure what is going to happen, but everybody is positive that it is going to involve a lot of pain and maybe death.

sounds fun right?

Every now and then, a boat makes it through this journey and pops out into the river below. The people on these boats likely will suffer from Post Traumatic Stress Disorder but by gosh, they made it! Commendable considering most boats do not survive this journey.

Now let’s move over to the Pond approach:

A project in Pond is represented by taking a boat out onto the pond and getting to a different side of the pond from where you’re starting out. Did I say a different side? Whoa, that’s not very goal-oriented, is it? Well, yes and no.

The goal is expressed with just enough detail to enable us to achieve it and at the same time have room to be creative and take advantage of any opportunities that arise. I figure we’ll decide where we want to land when we get closer. We can certainly make a better decision at the last minute, and it’ll be based on the best information possible (For instance, I have a bad back and I don’t want to have my picnic someplace where there isn’t a convenient place to sit).

So we set out onto the placid water. Everybody is calm. Nobody is stressed. We go to a different side of the pond and take a look at the shore. In unison, we turn to the person called the Pond Owner (or PO, for short) who just shakes her head. So, we turn away and go searching again (when the PO says No, she means No). To keep us from getting tired, we stop rowing every now and then to just sit back and listen to the breeze. Maybe we have a conversation about where to look next, or maybe we just nap. Sometimes somebody will clean up the boat just to make it a little nicer.

Eventually, we find a place that everyone agrees looks nice and we pull the boat up on shore. Our project is complete in a way that we couldn’t have predicted exactly because we’ve never been on this particular pond before. We’re ready to set out again just as soon as we’re done with the picnic. In Pond, you always have a picnic at the end of the project.

So now you know why I think the opposite of Waterfall should be called Pond.

In case you’re wondering, I’m a Pond guy.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Last week at Agile 2009, I attended a great panel discussion with previous winners of the Gordon Pask Award.

For those unaware, the Agile Alliance states that “The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate.”

Rally’s newest Coach Aaron Sanders facilitated this 90 minute sessions in three blocks: (1) Q&A with the award winners, (2) Q&A with the audience and (3) reflections by the award winners.

Here are some of my favorite insights shared by the panel:

Laurent Bossavit

• “Situational Learning concepts are important as people move beyond agile-by-the-book”
• Here to drive more innovations in “Diffusing agile into the organizations quickly”
  

Jeff Patton

• I am focused on coaching as agile has moved beyond selling into “How to do it.”
• Next up – practices for the product/business side to help them build “just enough”
  

J. B.  Rainsberger

• “I am interested in complex selling concepts as agile is trying to spread up.”
• BDD is just TDD done right (unit and acceptance/story test driven development) – pushes the focus to design and drops the word TEST – this is good.
  

Bob Payne

• Chicken’s and Pigs hurts when trying to create “One Team.”
• What’s Next – Create an “Agile Philanthropy revolution”

Arlo Belshee

• Us versus them – beat them is a human fear response
• Middle managers are often scared
• People who are advocating more then asking – are hard to build trust with
• Next for me is “Whole Company” and Governance strategies
  

  
  

  (Last year’s winner Kenji was not at the conference, but you can read a great interview with him on Aaron’s blog -  Interview with Kenji Hiranabe – 2008 Pask Award Winner – it gives you more of the flavor of the actual session)

It was great to see that they all had meaningful answers to the question regarding how the award had affected them.  Three cheers to Brian Marick for idea and Three Cheers to the awardees for making something out of it!  The highly interested members of the audience included Jean Tabaka, Esther Derby, Rachel Davies and about 20 other folks.

If you have not been to an Agile Conference, this kind of intimate gathering is common and why so many people come back year over year. It’s sessions like this that have helped Agile 2009 become such a wonderful mix of new and old, small and large as well as academic and professional.

I look forward to seeing Simon Baker & Gus Power from the UK and David Hussman, the newest Gordon Pask award winners, using their award to extend their influence on the industry.  Congratulations gentlemen and Congratulations to the team of volunteers that put on another strong Agile Conference.  See you in 2010!

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:

• Uncertainty Attributes: Market, technology, customer size, project duration, scope of change
• Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies

Three Perspectives

1. 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).
2. 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.
3. 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?
• Able to plan at multiple levels (with training)?

Is there a dedicated, persistent, cross-functional team?

• 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.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.