Agile Development Blog

Recently, I wrote the post “Escalation is Killing Agile – Can We Please Stop It?”  My passion around escalation brought 40+ in-depth comments.  With my travels and lack of internet access, I had been unable to sit down, sift through, and absorb all the various perspectives.  Until now.

I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.

In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.

According to the Systems Thinking Toolbox from Pegasus Communications, to break an Escalation structure, ask the following questions:

1. What is the relative measure that pits one party against the other and can you change it?
2. What are the significant delays in the system that may distort the true nature of the threat?
3. What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?

So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”

Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?

Here is an example:

I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post.  I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.

I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.

Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.

In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.

Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.

So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend.  If in our community we really “must win”  in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.

What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.

Here is a simple formula for bringing your viewpoint to bear without escalation:

1. Show up. (Be willing to be engaged.)
2. Find out what has meaning to you. (Be willing to be honest about your perspective.)
3. Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
4. Let go of what happens. (Be courageous enough to allow others to agree or disagree.)

I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.

I have some more mental models I want to offer here. But they will wait for another post.

Thank you in advance for your considerations, insights, and comments.

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.

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:

1. First the collection of individual contributors comes together to plan a limited portion of their own work. 
   
2. Second they set norms and limits that lead to common commitment to deliver working, tested increment. 
   
3. 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’s book “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.

About the Author: Ryan Martens is a fly-fisherman, 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.

Introducing Rally's Engineering Blog

As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.

This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.

I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams.  It is unique because of the open authoring model for all members of a fast growing set of agile teams.

With 15 posts published, and many more regular contributions on the way, I invite you to join me as a new subscriber to Rally’s Engineering Blog (click here to subscribe and here to visit the blog)

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.

In the last couple of months, IBM (via Scott Ambler) has blogged, hosted webinars and talked to the media about an Agile process maturity model (APMM).  I am sure this will hit a new height today with the start of the Rational Users Conference and the release of the e-book.  I have been asked to comment on this work by a number of press and analysts.  Since my perspective will be published shortly, I thought I would go on record.

IBM splashes its way into Agile development

As the Agile market grows and takes hold in truly mainstream audiences, everyone is looking for easy, step-by-step guides to smooth Agile adoption. IBM is proposing one option under the name “Agile Process Maturity Model.”  I think it is a nice marketing strategy for selling IBM’s Rational Team Concert products to companies that want to adopt the Jazz platform, copying their 90′s success with RUP.  But I don’t believe it is actually an Agile process maturity model, and further, Agile doesn’t need one.

IBM’s proposal for an Agile Process Maturity Model

Scott says, “The goal of the APMM is to help categorize and understand agile processes, not to rate your adoption level (the CMMI Defined approach can address that need).”

He continues, “Unfortunately, the term ‘maturity’ is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integration (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another…” 

I am confused by the title and the orthogonality, so let’s peel the onion on this one.

What is a process maturity model?

The origins of process maturity models come from the manufacturing industry, but the software version was created in the 1990′s by Carnegie Mellon’s Software Engineering Institute (SEI). It is well known as three Capability Maturity Models – CMM for software, CMM for people and CMMI.

If you read Watts Humphrey’s work, you will see this is a management framework that measures the level of discipline of  your organization. In essence, organizations that are certified Level 5 have implemented continuous improvement and have the disciplines and practices in place to effectively manage large complex projects with effective controls.  The framework does not say anything about how the software should be developed.  I make no claims to being a CMMI expert, but you can read a few of the “CMMI agile” search results to see how they work together.

Though not the stated intent of the framework, it has been closely associated with waterfall development and used to defend heavy process approaches. I disagree with that belief and prescribe to Jim Collin’s model of blending  discipline and agility together to move from good to great. I think the CMM framework is a great checklist for organizations measuring their level of discipline… and we don’t need another one.

The 3 levels of IBM’s APMM

Scott’s APMM post describes three levels:

1. Core Agile Development
2. Disciplined Agile Delivery
3. Agility at Scale

I struggle to see how these three labels or the supporting details provide a framework that helps categorize and understand Agile processes.  These titles grow in scope and scale, but do not speak to increasing agility.  (Faster cycles, less waste, less work-in-progress, more value.) When you look deeper, it smells of a cookbook of when to apply processes and tools from IBM.  That is fine, and I agree customers need this. However, I would argue this should not be used to guide companies in their Agile adoption.

By mashing size, scope, increased agility and disciplines on one scale, the APMM does none well.  In addition, it will lead to amateur implementations where continuous improvement mentality never sets in. Where adopting scaling software agility is thought to be just a transition from A to B.  To me that thinking is very limiting and will lead to gains followed by declines.

IBM in the Agile space – all good

I am thrilled with IBM’s entrance into the Agile space with their Jazz platform and related products – really. When I was at BEA/Weblogic, I can tell you that we did not have a market for Java Application servers until the industry’s gorillas, IBM and Oracle, entered for real.

During this year, Jazz and its supporting products will actually manage the workflow of projects in a way that works with Agile development instead of against it. This is huge change from the ALM 1.0 point products that actually reinforced the silos and phased approaches that created queues, caused hand-off delays and kept quality as an after-thought.

The IBM gorilla in the software development space will make the Agile sea rise and help break down major organizational barriers to bringing the benefits of Agile practices and tools to the mainstream development community.

There is no cookbook for adopting Agile

I believe that enterprises need an adoption model that helps them balance discipline and agility in an incremental fashion that creates incremental success and fuels continued investment and improvement. The enterprise Agile adoption model Jean Tabaka and I have synthesized is based on Lean concepts and is rooted in Deming’s work, just like Watts Humphrey and CMM. What Jean and I present in our whitepaper titled “Leaning IT: Moving to Program Pull” is how to move up the adoption curve of Agile by learning quickly,  maturing before scaling and working incrementally. 

This transition planning framework focuses on attaining benefits of agility by moving to lean states of flow, pull and ultimately the perfection of continuous innovation before adding the disciplines necessary to scale.  It discusses the general steps, but does not prescribe a change approach to organizational, technological, process or strategy transitions.   Your approach is dependent upon your corporate and technological situation.  We recommend an iterative approach, facilitated by experienced coaches and peer support.

What does the Agile community need from IBM?

Mary and Tom Poppendieck’s new book called “Leading Lean Software Development” (out soon) has tremendously strong stories, models and insights from bringing lean concepts to software. In chapter six,  they highlight a success story from working on lean with Sue McKinney at IBM.  This success story, along with the Eclipse success stories, are critical for IBM to be telling the market regarding the impact of Agile and Lean in the large inside IBM.

In 2008 and four years after IBM started developing Jazz, we talked to IBM about integrating Rally’s award winning Agile Lifecycle Management solution onto IBM’s collaborative development platform, called Jazz Foundation.  They said no, you have to wait until the GA release of Jazz. This would be a similar integration that we provide to Microsoft Team Foundation Server for managing code check-in’s and automated builds with a slick interface into the IDE.  I am hopeful that IBM will GA the 1.0 version of the Jazz Foundation for partners to actually integrate with.  They are saying all the right things on the Jazz.net site, here is hoping for some positive news at this week’s Rational User’s Conference.  Finally, I am very excited about IBM’s global dialogue on Building a Smarter Planet. IBM needs to do a better job telling the story about how software agility is a critical component to building that sustainable planet. (It was nice to see the smarter planet splash at the front of the ebook, but it still represents a huge missed opportunity.)

What do you think? Does Agile need its own process maturity model?

Again, I was surprised by the title of IBM’s Agile Process Maturity Model and hope they will consider changing it before more marketing dollars are spent.  It does not improve on the CMM, nor in my opinion does it help CMM certified companies adopt Agile.  I assume IBM has a huge role to play in helping those CMM certified companies add agility and innovation to their highly disciplined organizations. If they don’t, we are glad to help today.

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.

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

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?

The Denver Agile Success Tour continued with four open space sessions.  For about 20% of the room, this was the first open space session they have ever participated in. Groups broke into discussions on leadership, testing, scaling and tooling and then did a read-out to share their conclusions with the larger audience. (For my other live posts from the Denver event, see 5 Stories of Agile Success and What’s On Your Mind?)

#1 Open Space – Executives and Agile Adoption, led by Israel Gat

This group included new as well mature Agile folks and teams of 9 to 280 people – Given that spread, there was an overwhelming agreement that “our executives do not understand it” and “I, the executive, wants the whole iron triangle fixed – time, budget and scope.”  For executives who do not understand agile, it is very hard for people to communicate “What is in it for the executive?”

Conclusion – Socializing Agile is as important as doing Agile well. Your adoption will regress if your executives are not sold. Without time spent with executives, there is a bitter slide back down coming for the team. A slide like this is really hard to recover from.

Recommendation – At the point of scaling your agile adoption, contract up-front with your executive on the results, but only pick only one dimension. (Productivity, Time-to-Market or Quality)

#2 Open Space – Testing, Quality and Leadership, led by Zach Nies and Peggy Reed from Avaya

Topic time spent on willingness of test teams to move to Agile and what does pulling testing forward mean? Can I be Agile if I do not test inside the iteration? At Avaya, they do a lot of testing outside the iteration due a large matrix of configurations.

Conclusion – Make sure testing team is at iteration planning and release planning. Always honor your time box and retrospect on your testing coverage.

Recommendation – Focus on making story sizes smaller to bring testing into the iteration.

#3 Open Space – Scaling and Large Scale Adoption, led by Evan Campbell

Topics focused on collecting metrics while the guerrilla insurgency is working and before they get “busted” doing Agile.  The result of not collecting metrics means getting stuck in an “Agile Ghetto.”  Top-down adoption approaches are becoming more common, but came back to Rally’s Enterprise Adoption model called Flow-Pull-Innovate that is based on Lean.

Conclusion – It is inevitable that you are going to have to evangelize the Agile adoption.  Start building the case from day 1.

Recommendation - Focus on the change management process for large scale adoption.  Practices are a key focus for small teams, but not the key focus of large scale adoption.

#4 Open Space – Tooling Agile, led by Karen Kagiyama and Amy Wiley

Tools enable best practices, and integrations are inevitable because one tool cannot support all types and nuances of development teams and technology needs. Continuous integration,  build management and test coverage metrics and reports correlate into the context of iteration, release, and program of teams are critical for know “where are we right now?”

Conclusion – The ultimate goal is a single dashboard to support the insights and planning.

Recommendation - Use Rally’s Mash-up Platform to provide those insights.

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.

I’ve been talking with colleague and friend Israel Gat about the upcoming Rally Success Tour March 18 in Denver. In anticipation of the event, Israel has been talking with some of the people to be involved in both a panel discussion and breakout sessions. One of the panelists, Peggy Reed, R&D Director of Performance Solutions with Avaya, is someone I have known for several years.  With 30 years in the software industry, Peggy has expertise in many areas of software development. This includes enterprise integration, data visualization, data warehousing, and product development. She began her career in 1979 writing Motorola assembly language and has since moved into development management. She holds a degree in Computer Science from Colorado State University.

I know of Peggy’s passion around organizations, teams, software, and Agile in particular. She holds a conviction that this Agile forward thinking is the true foundation of delivering better software faster.  So, it was great to hear from Israel that Peggy spoke with him about something she calls “Beautiful Software.” I had an immediate warm reaction to this! Only Peggy could come up with such an intriguing notion about software.

In this post, I interview Israel about that very enticing notion that Peggy mentioned to find out his reactions and experiences in the world of “Beautiful Software.” We promise to not giveaway any spoilers from the upcoming event. We just want to poke around what  ideas come to us with the  term “Beautiful Software.”

Jean: Israel, thanks for joining me here. First of all, could you tell us a little about yourself?

Israel: I was born and raised in Israel. I served in the paratroop corps there and fought in the ’67 and ’73 wars. I came to the United States in ’76 and have lived here for most of the time since. I thought it would be good when I came in ’76, but little had I realized then how good it would actually be. I am very thankful to the country and the people for helping me make the United States my home. I actually feel that by sharing my Agile expertise I pay back my “debt” to the United States and to its software industry. For the better part of my professional career I have been doing system management. Since I got exposed to Agile in 2003, my passion for it has been steadily growing. About two years ago my passion for Agile had surpassed my passion for system management.  As of the beginning of this year I am devoting all my cycles to Agile, particularly with respect to consulting and coaching on enterprise level Agile deployments.

Jean: Great, Israel. Can you tell me about some of what struck you most about your interview with Peggy?

Israel: The PASSION. While I could not see her body language (this was a telephone interview) her passion for software was radiating through the receiver. I felt privileged and honored to speak with a professional who put so much of both her mind and her heart to software.

Jean: Thinking about Peggy’s passions and then about your own experience in the world of software, how do you think this term “Beautiful” applies? I mean, isn’t it a rather provocative and unusual description to ascribe to software?

Israel: I had a revelation many years ago when I first read the Cluetrain Manifesto: The End of Business as Usual. I realized then that I was a craftsman, not an assembly line worker. A true craftsman is proud of the intricacies of his/her work, striving for excellence and elegance while respecting the nature of the medium with which he or she is working. To borrow the title of a recent book, a software craftsman dreams in code. This sense of great discovery I had savored so long ago (while reading the Cluetrain Manifesto) was rekindled in me while I was listening to Peggy.

Jean: I don’t want to give away too much here about what Peggy will bring us next week. Still, can you tell me where, in your experience, a notion of “Beautiful” impacts organizational structure and business motivators?

Israel: Jim Highsmith talks of Intrinsic Quality versus Extrinsic Quality. Peggy’s notion of the beauty of the software is in some ways conceptually similar to Jim’s Intrinsic Quality. It is like the visceral feeling you get while holding an iPod in the palm of your hand – you know you are touching something very special!  I will restrain myself not to get deeper on the subject here as I might unintentionally steal some of Peggy’s thunder. I definitely plan to dive deep into Beautiful Software → Intrinsic Quality topic during the March 18 event in Denver. Stay tuned…

Jean: Well, thanks Israel for giving us some of your reactions and feedback. For people in the Denver area, I encourage you to come meet Peggy and the other panelists yourself March 18 for more about Agile adoption, Agile practices, and yes, even “Beautiful Software.”  Meanwhile, Israel and I will check-in here again after the event to report how others learned about and reacted to “Beautiful Software.” See you then!