Agile Development Blog

For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”

I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie.   There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile.  Now is not the time to stop and eat.

For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.

I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :

• a defined a bar that is deep in skill, knowledge and practice
• a significant enough bar to engage College and University study and examination
• research and curriculum that explore the tough questions in a scientific method
• development of more flexible or “T” shaped individuals that can see and work beyond silo roles.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

I encourage everyone in our community to figure out how to put energy toward one or more of these efforts.  The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking.  Thus broader education and difficult certification helps create a “Community of Thinkers.”  And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO 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.

I believe that Agile project management in small, co-located teams crossed into the mainstream back at the sold-out Agile 2007 conference, but Agile program management at scale is just now heating up. Last week’s article on eBay’s Agile adoption in Business Week (combined with other recent news) shows us that organizational agility is becoming a mainstream topic at the highest levels.

The market is no longer asking, “Can we scale Agile across the enterprise and large distributed teams?” and instead is asking, “How do I get there?” and “Who can help me?”

BusinessWeek asks, “Can eBay Get Its Tech Savvy Back?”

Watch the video of eBay's Mark Carges on BusinessWeek.com

Author Douglas MacMillan says: “Carges’ plan for eBay is to take the “agile” method of software development epitomized by the daily deal widget and expand it to other areas of the site. New product pages will be customized to better accommodate different categories, such as jewelry and clothing. And the company is helping third-party developers create applications for eBay’s site such as a UPS-branded terminal for monitoring shipments” Read the full article >>

Author Note: Mark Carges was my boss and mentor at BEA.  I know a good bit about his current efforts and they are really going for it at eBay and PayPal.  It is great that their enterprise agility efforts will unfold in public eyes.

In other mainstream signs of Agile…

I was excited to see a couple of other great articles on Agile this week, including:

• Marketers often say you’ve reached the mainstream market when you notice your peers are doing it, and you feel behind enough to move. InfoWorld’s Paul Krill noted in his article Software Companies Jump on Agile Programming Bandwagon how many providers are “eager to hop on the agile development train.” (Clearly, we have an early mainstream market now.) See my post about traditional providers, including IBM, entering the space.
• Gantthead’s Bob Weinstein handily made the case for transitioning to Agile development in his article on Making a Case for Agile Project Management. He says:

“If ever there were an ideal time to make the leap from a traditional to an agile project management approach, it’s now. In this tense, uncertain, cost-cutting environment where CIOs are watching their bottom lines like hawks, the concept unfailingly proves successful. It not only delivers consistent, excellent results on time, but often under budget.”

• Finally, David Rubenstein from SD Times tackles the issue of Agile Development Built to Scale. I agree with Robert Holler that scaling anything across an entire organization is tough, and that sometimes Agile just gets a bad rap for something that is universally a challenge. It does take commitment from the team, a bit of training and a lot of inspecting and adapting to be the best Agile organization you can be.

The question these days is: how good do you want to be, by when, and who’s the best partner to get you there?

The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ken Clyne

If a team member doesn't take accountability, things can get messy

With a four year old and a six year old, familiar sayings around our house are “pick up your toys,” “pick up your clothes,” “brush your teeth,” “get dressed.” Of course, as parents we could get our short-term objectives met much faster if we just did these tasks ourselves… but we don’t.

We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.

Giora Morein takes somewhat the opposite view in a recent Agile Tip of the Month article. He proposes that ScrumMasters (or, in my extreme analogy, the “parents”) should track hours remaining on a sprint on behalf of the team members (the “kids”). Giora says:

“Team members are focused on completing tasks and delivering value. The time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important. As such, the ScrumMaster should take on the responsibility of updating burndown data.“

While I don’t question Giora’s good intentions and there is no doubt this approach is expeditious, I believe it is worth striving to have the team update their own hours remaining. There are many benefits to being a member of a self-organizing, self-managing team, but with those benefits also comes responsibility and accountability.

Here are some dangers I see in a team not taking responsibility for their hours:

• They become less accountable for the number they provide

• They don’t understand the mechanisms of the self-managing, self-organizing team

• They become dependent on the ScrumMaster

• The ScrumMaster becomes frustrated and disillusioned

• The ScrumMaster morphs from a leadership role to a management role

• The team starts to revert to form

How does your team update its remaining hours? Have you tried one method that worked better than another?

#5 in our list of the Top 10 characteristics of an Agile organization is about the importance of practicing both Bottom-up and Top-down decision making.

In this 4 minute video, I talk about how successful Agile organizations embrace a notion of the ‘knowledge-creating company.’ In Agile, knowledge-creation can use “5 Levels of Planning” to ensure they are engaging in this whole organization practice. In sum, the highest level of planning, the vision, feeds and is fed by all subsequent levels, down to the lowest level of planning, the detailed daily work.

Watch my video for more about why I truly believe in both Bottom-up and Top-down decision making as a key success factor.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company and #6 Collaborative and Smart. Stay tuned for #4 in our series, Personal Flexibility and Rhythm.

Okay, I must be obsessed with Agile and PMOs lately. Well, Lean, too, as long as we are talking about obsessions.

Recently, I posted two blogs on the PMO topic: “Are PMOs Obsolete in Agile?” and “8 Ways to Re-tool a PMO in an Agile Environment“.

Now, in the upcoming Better Software Conference June 8 through 12, I will be presenting “Agile, Lean and the PMO”.

To summarize and entice, let me give you a quick preview.

PMOs usually think they are out of a job when Agile comes to town. But the truth is that a PMO can play a pivotal role in successful Agile adoption in large organizations.  In this presentation, I bring my experiences guiding organizations in how to engage their PMOs for successful Agile Adoption.

Enter three primary Lean Principles:

• Eliminate Waste
• See the Whole
• Amplify Learning

I intend to give examples of how PMO members act as the “systems thinkers” for their organizations, pulling Agile success outside of the engineering group alone and into the entire enterprise.

As I’ve stated before, there is a fundamental shift of the role of the PMO with Agile.

Simply stated, the PMO pulls standards versus pushing them;  the PMO provides product backlog prioritization guidance with regard to architecture and governance; and the PMO serves its Agile community by facilitating release planning across teams and creating and maintaining product councils.

In short, I contend that a truly Agile PMO brings “shocking openness” to the organization. This ensures deep, wide Agile adoption.

Let’s get together in Vegas to talk about PMOs and Agile and how Lean can guide us to take “what happens in Vegas” back to our organizations!

In an earlier post, I asked an Agile test question, “Are PMOs Obsolete in Agile?”

While the answer MAY be “Yes!”, I posited that there may be a way to save our PMOs from going the way of the now extinct dodo bird.

8 Ways To Re-Tool a PMO in an Agile Environment

1. Have the PMO involved in helping rollout Agile on several pilot projects

   This experience forms the roots for how the Agile PMO will engage throughout the organization with other project teams.

   Besides ensuring that Agile training occurs, the Agile PMO can become the coaches of coaches, training the ScrumMasters of each team. They can also be the Agile voice into the business to ensure the Product representatives are fully bought into their role in Agile.

2. Learn from Lean: start a Kaizen and Gemba mentality now

   The PMO should be the shepherds of continuous improvement so that the Agile adoption is not only sustained; it is vibrantly organic, every improving. This means moving beyond team-level iteration-focused retrospectives.

   Kaizen events create cross-team learning. This learning exposes team practices that can be useful at an organizational level. In such cases, the team practices are elevated to the organizational “Standard of Work” (see later item). Moreover, the Kaizen event clarifies when a practice does not serve the entire organization and can remain a team practice, supported by team agreements and adhered to by the team.

   In addition, in between Kaizen events, apply “Gemba”. An Agile PMO learns about the organization and spreads knowledge through the organization by being involved in projects. That means going to see, or “Gemba” according to Lean practices.

   Being engaged with teams rather than dictating from afar may be a dramatic shift in PMO behavior. And, it is pivotal to teams’ respecting the role of the PMO in creating a successful Agile adoption.

3. Change your definition of “Standard of Work”

   This is not a set of standards defined by and enforced by the PMO for project conformance.

   In Agile, as guided by Lean practices, a standard of work is a statement of what is currently useful, how things are currently done. It provides a team a backdrop from which to perform continuous improvement through Kaizen events such as retrospectives.

   (In my previous post on the PMO, Brendan Flynn has a wonderful comment about how he and his PMO engage teams at Shoplocal in doing this work.)

4. Facilitate and be a Servant Leader

   Don’t control.

   The Agile PMO, rather than controlling and patrolling, engages in facilitating teams in continuous learning. This PMO encourages empowered teams and amplifies the learning that arises when such teams are truly empowered.

   A great way to provide this facilitation and to engender cross-team involvement is to help organize and facilitate program-level and multi-program release planning meetings and product councils. The Agile PMO formulates a rhythm and a continuously improving agenda to help these meetings deliver the greatest benefit across teams.

   Along with being facilitative, Agile PMOs act as Servant Leaders. They serve their organizations by finding out what they need and getting it for them.

   They lead by serving. They remove impediments. They measure what is a problem for teams so that they can serve teams be removing the problem. They don’t look for status from teams; they look for how they can serve teams.

   So, for an Agile PMO, leading the Agile rollout means finding out what teams need and delivering that. It is about creating collaborative plans, not collecting statuses. For more about Servant Leaders in Agile, check out the first section of my book Collaboration Explained.

5. Provide guidance on regulatory adherence

   In organizations that must adhere to Sarbanes-Oxley, FDA, HIPAA, or other regulatory guidelines, the Agile PMO can represent these “red” (immutable) stories in each team’s Product Backlog.

   The PMO governance work can be the guide to each Product Owner on how to deliver the documents or features that help the entire organization remain in compliance with these regulatory constraints. Governance is now a service to project teams versus being a control mechanism.

6. Seek guidance from Lean to use Flow, Pull, and Innovate as guidelines for organizational-level Agile adoption

   Much of the guidance here has a hint of Lean about it. That is because PMOs work at an organizational level. Moving Agile beyond one or more pilot teams requires guidance for maturing and scaling.

   I recommend applying a 5-step approach which is based on Full, Pull and Innovate principles from Lean Thinking.

   Our Rally whitepaper about Applying Lean Pull principle for Program level Agile is a great guide for the Agile PMO working with programs of teams.

7. Guide non-IT/Engineering organizations

   Once Development group is working with the business to deliver prioritized, valued items, the Agile PMO can bring in other ‘back office” functions to help ensure a growing Agile adoption.

   Finance, HR, infrastructure, the executive team, and others must eventually all accept the Agile approach for true organizational change and value.

   The Agile PMO has an opportunity to be the mentors and guides for this growth and maturation.

8. Foster useful metrics

   Let go of that Waterfall security blanket around what are useful project or program metrics.

   Determine which metrics to track that directly help organizations concentrate on value delivery.

   Whatever does not deliver value is waste. It may be temporarily necessary waste. Or it may be a pernicious, embedded waste that has been assumed to be necessary.

   An Agile PMO ferrets out these “false friend” metrics and works with teams to determine metrics around value: test coverage, team velocity, agile adoption assessment, defect counts, definition of done.

   Look in the Appendix of our whitepaper A CIO’s Playbook for Adopting Scrum for more ideas on useful metrics in Agile adoption.

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.

note: PMO stands for Project Management Office.

To PMO or not to PMO? That is the question. Or, put another way, in our Agile test this week, please answer the following question:

Are PMOs Obsolete in Agile?

(a) YES!

(b) NO!

(c) Uh, maybe?

(d) All of the above :- )

What’s your answer?
Before you tell me, here is some food for thought:

Archeological Dig for Extinct Life Form

(a) YES!

Yes, if your PMO maintains a  rigid conformance posture informed by Waterfall approaches to managing and tracking project risk and success, it is obsolete. Lose it. Here’s why:

• Agile has no place for rigidity.

• Agile rewards flexibility, responsible change, and continuous growth. This is true in processes, in practices, and in people.

• Agile doesn’t seek conformance. Agile seeks emergence of the most useful, sustainable practices that deliver value, team by team, item by item, timebox by timebox.

• A PMO that determines standards and then enforces these standards through status updates runs counter to the core of Agile.

• Agile seeks more than status updates. There is no punishment or reward system other than finding impediments and removing them.

A conformance-based PMO, in contrast, will tend to hold onto old habits: create standards; enforce their standards; collect detailed status information about how projects are conforming to their standards; create pressure to bring non-conforming projects into line. Such a PMO can inadvertently (or purposefully?) create a culture of blame and hence engender skewed reporting by projects in order to avoid associated “punishments” or public flogging. This PMO with its incumbent culture will absolutely kill an Agile initiative before it has started.

So, if you find yourself in this environment, lose the PMO or you will never win with Agile.

(b) NO!

If your PMO is prepared to be a liaison and evangelist of the Agile rollout across the organization, don’t lose them! They can be a pivotal force that ensures the true essence of Agile; they seek to find out what delivers value in a regular rhythm and to keep improving on it.

The PMO has an incredible vantage point in an organization: they can look around and “see the whole”. Heads-down Agile project teams concentrate on what works in their singular context. An Agile  PMO, on the other hand, with a broader view, has the golden opportunity to continuously survey project teams to learn from them what is working well and then spread that good news to other teams and to the management.

An Agile PMO applying Lean Principles such as eliminating waste and amplifying learning can serve as the servants to the Product Owners and ScrumMasters. They can support the Agile project teams by facilitating cross-fertilization of best practices. They become the guardians and carriers of the Agile emergence. You might say they are act as the Agile pollinators.

Note: see my post “8 Ways To Re-Tool a PMO in an Agile Environment” for further information about how to create an Agile PMO.

(c) Uh, Maybe?

Ultimately, it comes down to this: What transitional fortitude does your organization have to move to a new way of doing things: the learning, the facilitation, and the Servant Leadership required of an Agile PMO?

That is the big MAYBE that will be sitting like an elephant in the room with you as you consider an Agile rollout with your PMO.

My Rally colleague Mark Kilby has a great way of testing this: Is your PMO prepared to sign an Agile PMO Manifesto?

We, as an Agile PMO, value:

• Kaizen (retrospections for continuous improvement) over Conformance and Consistency
• Org-team mutual Service Level Agreements over Top-down Policies and Processes
• Communities of Practice over Central Authority

(d) All of the above :- )

So, where are you, where do you want to be, and how do you hope to get there? You may, at any time, be any one of the above, or all at the same time. Fear not! There is a way.

Just remember, answer (a) YES! reminds us that a traditional PMO has no place in a  truly Agile organization and is hence obsolete.

To get to answer (b) NO! your PMO must be prepared  for jolting change in its principles and practices. It may seem daunting. But Agile and Lean have great guidance to protect you along your path.

And, at any time during your Agile Adoption, you may find yourself in the ambiguity of (c) Uh, Maybe? or (d) All of the above :- )

If you are prepared to embrace the 10-step Agile PMO guidance and Mark Kilby’s Agile PMO Manifesto, you will be on the righteous Agile PMO path.

So, now tell me your answer to the question: Are PMOs Obsolete in Agile?

Question: How did you get started from waterfall?

Answer 1 -  Started with whiteboards and sticky notes.

Answer 2 – Started with in-house tool, then open source and finally Rally.

Answer 3 – Started with Rally training for the first year with a Rally pilot in parallel to show management and staff the whole solution.

Answer 4 – Put good consultants alongside the team from day 1 to apprenticeship with the best – we went Rally training and consulting.

Question: We have lots of concurrent features in parallel. Does anyone do concurrent feature branches?

Answer 1 – Peggy – At Avaya we do this, but first go back to the product owner to prioritize better.  We use private views in ClearCase to manage features branches with continuous integration in the views.

Answer 2 – Israel – Never allow the backlog to be larger than twice the capacity of a release.

Question: Please talk about the adoption challenges of adopting with your external customers.

Answer 1 – Israel – It took us 18 months to change the perception of my group with sales.  It was critical to get field engineers to come to release planning and every iteration demo. They get exposed to the software engineering approach and real status and built the best evangelists and advocates in the process.

Answer 2 – Richard – Rally has developed a social networking site with what most people see as shocking openness.  As a result, we have had tremendous success in engaging customers and focusing priorities.

Question: What is the cheapest and best way to get started as an individual?

Answer 1 – Take trips to visit other local companies – everyone says yes.

Answer 2 – “XP in Trenches” – was recent great book find- read a ton of books but most only focused on single team.

Answer 3 – Richard – Come be a fly on the wall at a Rally release planning.

Question: Big Six Sigma background – What tools do you use QFD to find what customer really wants?

Answer 1 – Failed with all upfront tools, only thing that works is communication in every iteration.  Too many edge cases in our industrial software.  Given up trying to spec this in advance.  Invest more in bringing the customer in.

Answer 2 – Israel – Try to reach the point where the developer can code faster than marketers can release.  As soon as that happens, you can decouple and get more feedback during the cycle.  You are also able to bring more of the business into learning after you decouple.

Question: How do you solve the coordination of many teams in a large adoption? Tell me more about Meta Scrum.

Answer 1 – We do a meta scrum every week with the owners of seven product lines.  In parallel the product owners and development leads do the same.

Answer 2 – Israel – Scrum of Scrums everyday with all the ScrumMasters following a 10 to 15 minute approach.

On Thursday, March 19th, Dave West from Forrester Research and I will be doing a live webinar titled, “Scaling Agility with Lean: Proven Methods of Operational Efficiency.” It is part of a webinar series regarding “Using Agile to Cut Development Costs.” Our own Jean Tabaka and Global Logic’s Johnny Scarborough did the first webinar titled “Realizing the Promise of Agile: Creating Leaner, Meaner and Faster Product Development” and it is available via recording by registering at this same site.

In this week’s webinar, I am going to share a set of models that I  keep being asked about. These slides show the changes that happen in the enterprise stage gate model as your Agile adoption moves up and matures in the organization. To hear the explanation behind these slides and see Dave West’s work on Lean, please join us on the webinar.  The full slide deck will be available after the webinar.

Not to steal all of my thunder, but there are two things that interesting about this transition.

1. The Agile stage gates of 3.1/4.1 actually provide more governance control than the old gates.
2. The first and last gate are not going away in large organizations anytime soon. You just don’t start projects without budget and you do not make a gold master for production without blessing from operations or overall system testing.

Lastly, Dave’s observations about how these stage gate models require a Lean organization approach, should make for a great conversation. I hope you will join us.