I just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.
Jean and I have had a great time writing these posts over the last year, and we are humbled by the way you’ve responded. After a few years of casual, intermittent posting in our Agile Commons community, we jumped off the deep end into blogging this year by hatching out this site and our Engineering Blog.
We are truly grateful for how you have helped us learn and grow: for every comment, every tweet, everything that you have shared with us.
And we are hopeful that the learning has been a two way street. That is, whatever topics or ideas we posted in the blog that particularly resonated with you, we are honored that you invited us into your 2009 professional journey. In fact, we’d like to see your comments on what you found particularly useful or engaging in this past year. And we welcome your suggestions for topics in 2010.
We look forward to continuing this great conversation in 2010.
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.
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:
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.
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:
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!
I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what succeeds versus falls back, I do not believe their is a “cookbook” for Agile adoption. Of course, the question then becomes:
If there is no cookbook, then what is the best approach to succeed with my Agile adoption?
Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.
The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking. However, Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations. In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.
Getting Over the Hump - Critical Step #3
Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)
We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.
What do think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?
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:
Core Agile Development
Disciplined Agile Delivery
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.
As geeky as it sounds, I love learning. When I was first exposed to the world of organizational learning back in the 90’s, I picked up a couple of handy phrases that I chant on weekly basis:
Learn – Teach – Learn
No Theory, No Learn
These phrases capture two of my mental models on organizational learning. Mainly that it is an iterative cycle, only comes through sharing, and requires reflection and measurement on your theory to learn. With that in mind, we frequently open our doors to our customers to Learn and Teach. They observe our stand-ups and planning meetings and we discuss how Agile development has infiltrated not just our development team, but our entire business. I always try to ask them – “What is your Theory?” before they come.
Creative Commons Kathy Sierra - Click to view her blog post on the topic
What’s Your Theory?
Many organizations are simply happy to take the first step toward the smooth and continuous flow of Agile development. But what I love about working with many of our customers like Pinnacol Assurance is their desire to go beyond amateurism, what Kathy Sierra shows as the road to becoming an expert. Amateurism is not enough; they want to become experts by fully adopting Agile throughout their organization and through a continuous improvement process.
At our last release planning session in April, members of the Pinnacol’s IT team participated right alongside our internal team. Wednesday of this week, members of Pinnacol’s leadership team shared in our company-wide rhythm of daily stand-up meetings, rotating through a variety of stand-ups from the dev team to IT to marketing.
How about a Learning Journey?
The goal of their trip was bringing mental models from outside of Pinnacol into their organization. I love that approach and it’s one we use ourselves at Rally. If we see a company doing something particularly well – whether it’s supporting their customers or hosting an out-of-this-world event – we ask to visit their company, shadow them for a day or two, and get first-hand knowledge of their success. It’s one of the best ways I know to quickly learn a model in a very hands-on way and almost immediately translate that into success at your own company – all without reinventing the wheel. Otto Scharmer who developed Theory U calls these trips – Learning Journeys. They are the first step to help you see what you do not know and getting you to open up and learn as a team.
Pinnacol has been very successful at attaining the benefits of Agile in flow inside of IT, but they are already looking above and beyond. They brought business representatives and operations leaders to share and learn about increasing agility in a larger, enterprise-wide context. I am really looking forward to hearing more about Pinnacol’s path to fast learning. You can read about Pinnacol’s adoption of Agile and Rally in the case study.
When Agile teams start to plateau (or worse yet slide back to the old ways), I often hear this complaint:
“There is too much time in meetings with Agile Software Development, we give up!”
I usually follow that up with a question: What are you doing to fix that?
An overabundance of meeting time is a problem that many organizations face, but I’d argue that Agile practices are the solution instead of the cause.
If I can get the team to ask me for suggestions, I always point them to my friend Jean Tabaka’s great reference book on running Agile meetings – called Collaboration Explained. But today I saw yet another wonderful nugget from Seth Godin about general meetings.
Seth Godin’s Suggestions on Serious Meeting Practices
Many of his suggestions relate to the practices of Agile and are disciplines we use at Rally to keep from meeting to death. Seth’s portion in quotes below:
“Remove all the chairs from the conference room. I’m serious.“
New employees to an Agile team or company often laugh at the idea of a daily stand-up meeting, but literally standing during the meeting encourages people to be concise, attentive and then get on with their work. The best stand-ups at our company happen at around 9:00 am daily.
“Understand that all problems are not the same. So why are your meetings? Does every issue deserve an hour? Why is there a default length?“
Agile helps us drive this discipline. Stand-up meetings are less than 15 minutes, iteration planning is a half-day for a new team and 1-2 hours for seasoned team. Release planning is a 4 to 8 hours and my require a part of second day to handle dependencies across multiple synchronized teams. Allocate the right time for the right purpose, and bring in a professional Agile facilitator (or assign a neutral party from another department if you don’t have the budget) to keep the goals of the meeting moving. Having a agenda with time limits per section helps. So does a big buzzer (we have one of these at each table of attendees) to hit when people get off topic.
“If someone is more than two minutes later than the last person to the meeting, they have to pay a fine of $10 to the coffee fund.“
We do this at our executive stand-up meetings (with a slightly lighter sentence), and recommend customers do the same. Late attendees pay $1; if you’re late AND the last one in the door, it’s $5.
“Require preparation. Give people things to read or do before the meeting, and if they don’t, kick them out.”
Before release planning, we create a collaborative web site where materials are stored. All pre-reading is assigned in advance, and all attendees have to load their slides to the site before the meeting begins. We even have a “no thumb drive” rule to discourage last-minute slide creation.
So what’s my point? Don’t blame the methods and practices for your lack of personal discipline and commitment to get better.
If you are going to win in this global economy, you have to find ways to constantly improve, and Lean and Agile development are proven cures. It is too easy to give up, so instead stand-up and, as Christopher Avery teaches, take some personal responsibility to make it better – start from within!
Do you have other meeting guidelines that you’ve used successfully? How much of your company’s meeting addiction gets blamed on Agile practices? How has your organization adapted to better meeting discipline?
Did you find these posts valuable? Any advice on how we can improve this for next time?
Agile 101, led by Christophe Louvion
What is your pain? Command and control, changing priorities during the sprint, hybrid process, making decisions outside the team that affect the team, improper tooling, moving resources around.
Root causes: Lack of self organization caused by lack of education, lack of an Agile driver, internal or external customer pressure, lack of executive vision, fear of change, skill set mismatches, ask teams to do things that don’t work well, lack of action items with a clear owner and clear deadlines.
Christophe had people in his breakout commit to action items. Christophe is going to call each of these people and verify if they accomplished their action items, like Lisa who committed to requesting a coach to come into their company and help them with their hybrid Agile process.
Pains: The sausage factory syndrome, the business doesn’t want to know how the software is made, but give me what I ask for when I need it. Market dynamics like drops in ad revenue and other drops in the market.
Solution: Innovation is now affordable because we can all experiment, try something in your sprint and if it doesn’t work out you only have 2 weeks invested. Read the book Innovators Dilemma by Clayton Christenson.
Risk management is important to executives, and Agile reduces it significantly. Money quantification, understand the value of what you’re delivering. Look at Capers Jones and his 2008 book Applied Software Measurement and his 2007 book Estimating Software Costs.
Agile Governance and Compliance, led by Laureen Knudsen
Pains: People live in rigid environments and don’t want to change. People don’t want to show their work because it’s too raw and there is fear around failing fast by validating your work with actual customers. There were questions about what is the earliest point to show things to customers.
Organizationally what is happening to enable collaboration? Organizations need to communicate down about vision, and the teams need to communicate up areas of process improvement. There was talk about servant leaders, and how command and control managers actually make people dumber. Most Agile teams start with iteration planning, standups and the end of the iteration demo.
Start with a Vision, this is the first level of planning that the leadership team owns.
Then move to a Roadmap where you talk about themes of releases. It’s important to talk in themes and the Product Council is the feedback mechanism for that process.
Then Release planning is next. It is important for everyone to be involved in the Release planning.
Then think about taking the Release theme and how the Iterations build toward that goal.
Then Daily examine what you did toward that goal yesterday, what you are going to do today, and what is getting in your way.
Each level then provides a feedback loop to the higher level of planning. At Rally everyone is involved in these 5 levels of planning within every department in the company.
Pains: Integrating testing teams in with development teams, making testing teams more effective and how to introduce Test Driven Development into the development team. An important way to integrate testing and development is to integrate and involve both roles in planning sessions. Testing should be part of the definition of done and involve testers in creating a story’s acceptance criteria.
The group talked about how to break down the walls between testers and developers, by focusing on the reality that everyone owns the quality of the software being developed. When testing is integrated into the process it makes them more effective. Finally, a few teams are trying to use Test Driven Development. Test Driven Development can’t be imposed onto the team, the key developers on the team need to lead by example by embracing TDD practices.
This and other great questions from the LA Agile Success Tour below. My next post will cover the open space breakout sessions.
Question: What would you ask your CEO to bring Agile into your organization?
Christophe – Are you ready to get rid of 50% of your managers? Jean – Agile brings about organization change, 20% of engineers won’t adjust. Israel – What are you trying to accomplish? Pick one and focus on it. Chris – Why just Agile in engineering? The whole business can use Agile throughout the whole organization. Laureen – Are you really committed to the change?
Question: What metrics do you ask the teams and upper management to embrace?
Chris – Measure what you want to improve and care about like: velocity, unit test coverage for the team. For the executives, align business metrics with your development metrics and make it as public as possible. Laureen – Make sure you have a goal before you come up with your metrics. What do the metrics mean to us? Data should support your goals. David – Had no metrics before Agile, now we can have value based metrics that the business can use. Israel – Establish a baseline before you do any process changes – you need to know where you stand. Pick the metrics to help you know where you stand and establish that baseline. Christophe – One tracked 3 metrics: dollars, customer satisfaction, and time to market.
Question: What do you believe is the #1 discipline that had to change or understand to enable successful Agile adoption?
Chris – The toughest and most important one is getting the development team to embrace continuous integration, it reveals so many of the improvement areas within the development team. This is hard because it can expose so many sacred cows within the organization. Getting to a point where you are always ready to release is key. Israel – Changing how the sales force and marketing departments sell products. Getting these groups able to sell value and benefits to the customer rather than a pure feature focus. This is key to end-to-end Agile. Laureen – Agile isn’t just another process with associated documents; it’s a change with how people interact with each other on a day to day basis. If people don’t want to grow and change with the business, then they may need to leave your organization. Christophe – Are you good at multitasking? Instead ask: Are you good at single tasking? Limit the amount of work in progress! Nothing gets done when you focus on too many things. The most difficult thing is to get teams to focus on one thing at a time. David – Moving away from an upfront requirements document to user stories that can change over time. A key piece was to break the stories down into smaller and smaller stories that can be worked during the iterations. Even people who thought they understood this process of breaking stories down struggled.
Question: How do you educate clients to Agile in a service provider based businesses?
Israel – Involve your customers with the iterations, the release planning events, and the end of iteration demos. The commitment is small from the customer and the benefits are tremendous in that the customer can be involved in the development process. Chris – Agile is such a wonderful and easy way to get customer involvement. Each iteration, they deploy to an external environment where they get feedback. Create a feedback loop with your customer so they can see how their feedback affects the direction of the product.
Question: How do you do performance management in a highly functional organization?
Christophe – I don’t do formal performance appraisals in my organization. Do the right thing for your team. Jean – Look at performance with this question: In what ways did you contribute to the success of this team? David – Unlike Christophe, it’s a little different in big organizations with SOX issues. If you have managers that span Scrum teams, make sure they understand what’s going on in the Scrum teams. Your focus as a manager totally shifts from micromanagement to one of removing impediments, roadblocks, and preparing the team for the next project. Israel – Keep information about how the team is doing secret to the team. Decouple the performance appraisal process from the process improvement within the team.
Question: How do you estimate how much work will go into a release and do more development and do it faster?
Christophe – Make sure you fix the date of your release and vary scope. David – I agree, resources are fixed, time is fixed and scope varies. Laureen – We use a train analogy. There is no question when the train is leaving, the question is what features will be on the train. David – When we started we had about 60% estimation accuracy. We now have over 90% accuracy in our estimates. A key point is DON’T LOAD YOURSELF TO 100% CAPACITY. Give yourself some flexibility, someone might get sick.
We received lots of great questions and shared them with the webinar attendees, but thought they would also be valuable to other Agile practitioners. This first series of questions tackle the obstacles of adopting Agile. Stay tuned for the remaining questions in later posts.
What are the biggest blockers you see to good Agile?
DW – My pet peeves are people that resist change without really thinking about it. That treat software like car production and think that you can plan, deliver in that manner. These same people often lament the ability of the software teams to deliver good code at the right price. Software is a fundamental part of business change – If you need a new part to your business it will most likely require software, which may require development and integration. Connecting up their development with the people who have the problem is the first step to success, empowering teams to try new things and question the status quo in support of those business needs is key. Organizations that put artificial walls between the problem and the solution are the biggest blockers. These may come in the form of planning processes, business access, travel budgets, governance models, standards or culture.
RAM – Good Agile development is a mindset change like Dave is describing above. Overly aggressive or passive plans are the biggest blockers to “good Agile.” You need to think about this change as incremental and iterative with a strong focus on continuous improvement and learning through inspect and adapt feedback loops.
RallyDev.com
I just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.
Last week at Agile 2009, I attended a 
and CMM. What Jean and I present in our whitepaper titled “
