Last week, I had the pleasure of attending a talk given by Geoffrey Moore. You may know him through his renown as the author of “Crossing the Chasm“, “Inside the Tornado“, and his most recent book, “Dealing with Darwin“. Geoff is an energetic, articulate speaker who always has interesting insights and mental model twists to share. On this particular occasion, Geoff had been sponsored by Rally Software to speak at the annual Toolapalooza event at Cisco. His topic? “The Future of Enterprise IT”.
Geoffrey Moore asking for a show of hands from the crowd about their social media use.
What most struck me about Geoff’s talk was his query about what we are currently capable as consumers versus how we are held back as employees. Specifically he was speaking about the technologies in social media that are growing and advancing at an alarming rate.
As consumers, we engage in MySpace, Facebook, Twitter, YouTube and all sorts of other emerging social media. We stay connected. We collaborate. We can instantly survey one another. We can quickly comment and offer direction.
In other words, we have an ability to maintain a presence regardless of time or location.
In contrast, we are not embracing these social media tools within our corporations. Essentially, as Geoff put it,”We are more productive as consumers than as employees. Why can’t I have my tools at work?”
Specifically, he spoke of the need for Enterprise IT to move from its role as “system of record” to supporting enterprise search, enterprise facebook, and enterprise mobility (as examples).
Enterprise IT needs to make a fundamental shift: from being the core of the operations of a company and being data-centric, to being at the edge of the company’s face, being very network-centric.
For this audience at Cisco, this wasn’t too much of a stretch in mental model shifts. Cisco has been leading corporate collaborate shifts, most notably through their Telepresence technology. You’ve probably seen the ads on T.V. for this remarkable collaboration technology. (BTW, the Telepresence project effort determined that they HAD to use an Agile approach in order to deliver their product in a timely manner. And, they chose the Rally tool to support their multi-team effort.)
For me, Geoff’s talk nudged me into that realm of the “blindingly obvious”. I really hadn’t thought about how the social media in my consumer life have not been effectively absorbed into my corporate life, either within my company or in the community of companies with whom I consult. I have believed in creating collaborative communities.
It has been a passion of mine in guiding organizations in their Agile adoptions. Geoff’s insights just confirmed to me, my passion now has to invite the consumer world of social media into Agile, collaborative organizations.
During my CSM training eons ago under Ken Schwaber’s tutelage, he likened the relationship of the development team to the product owner and stakeholders as one of Pigs versus Chickens. It is based on an old joke about commitment and involvement for a pig and a chicken opening a restaurant. Hmmm. Not sure about that analogy, but okay.
Enter Mike Vizdos. Mike is a great guy and a friend as well as a revered colleague in the Scrum Trainer community associated with the Scum Alliance. Mike has taken the Pig and the Chicken Scrum analogy where it has never gone before.
In the cartoon section of his website, Mike has collected a great series of hilarious insights into the life of the Pig and the Chicken. With the aid of professional cartoonist Tony Clark, Mike leaves no topic untouched. There are no sacred cows! Oh no! another animal reference! What I meant to say is that Mike brings out the elephant in the room. Yikes! Another animal! Okay, let me put it this way: I’ve got an Australian blue heeler nipping at my heels to let the cat out of the bag and squeal like a rat about the tiger Mike has by the tail, even though this might all sound very fishy :- )
I love Mike’s wit and honesty. I invite you to enjoy Mike’s farm animals and poke around at the rest of his site as well. There may be some other interesting characters lurking….
In this 3-minute video, I share how organizations can achieve this balance through (1) stability, (2) sustainable pace, and (3) redefining success based on what the customer sees as most valuable, not just meeting the plan.
In this post, I’d like to respond to some questions posed to Johnny and me during the webinar.
JET = Jean Tabaka
What is the measurement of productivity? Is it user stories per lines of code?
JET: We define productivity index with regard to the Michael Mah statistics collected over 7500 products. It is not about lines of code. Rather it is about delivered value. At a very high-level view then, a PI in an Agile team is about the amount of value delivered by a team based on value delivered over the total number of team members.
Michael Mah shows in his studies, which we referenced in our webinar, that Agile teams tend to have a higher ability to delivery value per team member than the norm across all projects he has surveyed. This supports our view that the way to project cut costs is to help team members increase their PI versus cutting team members or off-shoring work.
When you start on Step 1, one team in flow, do you start immediately with 2-week iterations, even if the teams are used to waterfall?
JET: For any team starting its transition to Agile, the important Flow guidance I give is: Choose a timebox, and stick to it. Religiously.
I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.
A shorter timebox invites earlier improvements on process. It also affords the Product Owner or customer representative the opportunity to re-prioritize, add, or delete items in their backlog.
Given these parameters, the team commits to what the timebox length will be. So what do I advise? If asked, I tell teams that 2 weeks is a good starting point: shorter time to inspection versus longer wait for improvement opportunities.
How would you apply Agile, and particularly Scrum, to security related software where design and reviews typically take longer than one iteration?
JET: Agile asks us to evaluate how much design and review MUST occur before features can begin to be coded and tested. Your question is all the more important in your context.
Think of it this way: Imagine in a security software environment, you implemented something and then slammed all kinds of vulnerability tests against it to discover its actual vulnerability. Imagine that this could be in addition to, or even as a replacement to, extensive review up front.
I once worked in a security related software environment. We spent months and months reviewing documentation attempting to conduct independent validation and verification about vulnerabilities before any coding began. How I wish we could have just conducted detailed design, code, and test on our riskiest features and applied our hypotheses against these rather than being left to hope our analysis was adequate!
If we want to introduce Agile in a certain project team, what’s the perfect ratio of Agile consultants versus our own personnel?
JET: Perfection is in the eye of the beholder ;-)
I suggest one mentor per team initially. We have also used one mentor for a team of teams, a program. That creates stability and synergy across the teams and encourages all teams to form their own Agile team agreements while also learning from what has worked well with the other teams.
One more thing: Having a mentor at the management/executive-level is also critical. It may be this same person; it may be someone who has more of an executive stature. In the latter case, be sure the two mentors work tightly with one another.
Would you define ‘user stories’? Similar to Use Cases? Difference?
JET: User stories are an expression of a request from the customer or customer representative for a particular function. They are meant to be short, incomplete, and value-based.
They invite conversation and further clarification of completion: “As a < role >, I want to < action > so that I can < benefit >.”
“As a dog, I want access to ‘The Daily Woof” newspaper on my Kindle so that I can flip pages without opposable thumbs.”
This request for action and benefit is elaborated as it rises in rank among all functions requested. We elaborate these in several ways. One way is to start writing acceptance criteria.
Another way might be to elaborate it through a use case that details actor-system interactions, extensions, and so on. A team makes agreements about how function requests grow in clarity; that is, are use cases our best way to declare DONENESS for this request? Or, in our environment, is a simple description and test case sufficient?
How can we get better reporting metrics for roll-up to the executive level? Are there key mash-ups I should/could use?
JET: without digging into specifics with regard to mashups in our Rally tool, I highly recommend looking at a set of metrics we gathered in our whitepaper: “A CIO Playbook for Adopting for Adopting Scrum” co-authored with Ken Schwaber and Dean Leffingwell.
One appendix in the paper guides teams in a quick self-assessment of their Agile uptake. The second offers metrics both teams and executives can use as new measures of success.
Altering how we measure and guide success in Agile has a great impact on the “stickiness” and intended benefits of the Agile rollout. Rally tool mashups simply support real-time access to such measures. This “reporting” style deviates from the traditional “reporting up”. Rather, the metrics we recommend are meant to keep the entire organization informed about what is really happening. This creates organizational ownership of amplified learning and continuous improvement.
Have you integrated user centered design (usability practices) into the Agile development process? If yes, what was your approach? If no, why not?
JET: I believe user-centered design has a place in Agile development. Design emergence doesn’t mean it can only occur in the planning meeting for the next iteration, IMHO.
creates a high-level vision (informed by many sources);
collaborates with the product owners about how to incorporate this across a product roadmap;
provides more detailed guidance about backlog items specific to the user-centered design;
then engages actively within Scrum teams when product backlog items specifically impact user design changes (where she is tester or owner or delivery team depending on the item.)
Do Agile practices only apply to software delivery, or have you ever seen them applied to successful service delivery?
JET: Jeff Sutherland tells a great story about helping his wife apply Scrum in her life as a Unitarian minister. I also have a colleague who uses it in his volunteer organization. And there are people in my Certified ScrumMaster classes from non-software parts of software organizations eager to bring Agile in. Here at Rally, we use Scrum in EVERY department in the company, including at the executive level.
It is already challenging to obtain the time of critical resources (shared among various projects and sustaining). Are every day SCRUM meetings practically possible?
JET: Everyday meetings are faster than having to write them extensive documentation. And, they are less costly than not having them involved at all. Still, teams make agreements about how critical it is for “part-time” experts to be engaged in every meeting. They inspect and adapt.
Is Scrum mostly for R&D projects with more unknowns or is it equally effective on projects with extensive functional and technical knowledge and skills.
In other words, is Waterfall totally obsolete?
JET: Rigid methodologies don’t serve environments where any amount of change can occur. If you have projects that have no change in scope, no mis-interpretations of requirements, no defects in design, no defects found in code test or integration that would require re-work, I see no reason for you to change. I do not know of such projects.
And why is this so important to a successful Agile organization?
Watch this 3-minute video for some of my ideas and 4 of the 10 characteristics of a Servant Leader from Robert Greenleaf. Or, see my full hour-long Servant Leadership webinar for a more in-depth look at this #9 characteristic of an Agile organization.
About the Author: Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
Never back down from an intelligent debate - or whatever these idiots are doing
The question over product management vs. product ownership is a huge issue that many companies face as they try to scale Agile. Dean Leffingwell just finished up a great series on Agile Journal in which he makes the case that the Enterprise Product Manager is Likely NOT the Agile Product Owner.
The Agile Journal article series is a great place to jump into the debate, but his blogging on Scaling Software Agility is also excellent and very deep – what Dean tends to call “pithy.” I am sure some of you will call foul with some of Dean’s points, but his methods have proven to be very effective with large-scale agility. I’d ask, are you skeptical based on personal bias or real Agile principles?
Here are four other resources that are great at analyzing product management and product ownership:
Final note to readers: Dean is a good friend of mine, and he helped me start Rally. He is an investor and worked for us between 2003 and 2005. Now he does his own consulting on large-scale Agile and continues writing for Prentice Hall. I cannot thank him enough for his personal support in shaping my thinking around large-scale software development, building a network into some of the world’s best practitioners, and coaching me as an entrepreneur. He is a passionate software craftsman.
Thanks, Dean, and very nice work on this critical topic.
Jean and I made a commitment this quarter to go deep on Lean software development. We have been working with Lean and Agile for years, and really want to engage you in a dialogue to help explore the topic of how they relate.
Jared from Subway on his exploration of a different type of "lean"
To help focus our research, tell us, what are your favorite resources for Lean and Agile?
I don’t want to bias your feedback too much, so here are a few of our current favorite resources as a jumping off point:
Lean.org – Jim Womack’s site about Lean across industries
We learned last week that Rally has been recognized as one of the top 10 companies to work for in America by Outside Magazine (look for the complete list in their May issue and on Outside Online around May 1st), so we figured we’d start things off by covering one of our most prized characteristics, how to have work… and a life.
In this brief video, I share how organizations can effectively achieve work/life balance through a combination of (1) discipline, (2) rhythm and (3) alignment of corporate and personal culture.
How do you balance work and life to achieve success in both?
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
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.
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.
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.
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.
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.
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.
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.
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.
Is it a blob that will cause you to lose all control, including your job?
Or, is it an amazing innovation that will save your company from this world-wide recession?
Or the it's The Blob - Buy the classic @ Turner by clicking image
On April 15th, I will be fortunate enough to join Sachin Saxena from Global Logic and Mac Devine, the AIM SaaS/Cloud CTO at IBM, for a webinar to attempt to answer these questions (learn more and register here). They are both experts in internet technology and hold deep knowledge (along with beautiful slides) on the topic of cloud computing. Their goal is to help you understand the massive energy, time and computer savings made possible by the many cloud options.
Specifically, they will define the cloud, its opportunities and roadblocks. They both plan to highlight case studies, and my role will be as a customer and extensive user of cloud solutions. This is much the same role that I played at the New Jersey CIO summit in February. (If you can’t wait for the webinar – don’t miss Troy Angrignon’s opinion post at Sandhill.com about the implications on cloud computing on software firms.)
At Rally, we are very comfortable with the application of these technologies. As a 160 person SaaS firm provider, we have been in the early market for many of these technologies. It was fun for us to benefit from the fast move to free of hypervisor/virtualization portion of this wave. Listen to Mike Cote’s podcast on the topic at RedMonk. He has been covering the Cloud/virtualization for years as an open source analyst.
As a result, I believe that 100% of the companies who attend this webinar will leverage these technologies in 2009 in a strategy to reduce risk and cut costs. But what are the other rationales for the cloud? What are your stories? I think cloud/SaaS, Agile development and web 2.0 customer communities are an even bigger story, but one that will take longer to develop than the use of public/private clouds and virtualization technology.
Next up on this topic will be the actual energy savings reports from our virtualization and power management efforts lead by our internal green team.
RallyDev.com
Last week, I had the pleasure of attending a talk given by Geoffrey Moore. You may know him through his renown as the author of “Crossing the Chasm“, “Inside the Tornado“, and his most recent book, “Dealing with Darwin“. Geoff is an energetic, articulate speaker who always has interesting insights and mental model twists to share. On this particular occasion, Geoff had been sponsored by Rally Software to speak at the annual Toolapalooza event at Cisco. His topic? “The Future of Enterprise IT”.
#8 in our list of the 
I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.
#9 in our list of the 
This is the first post in our series that counts down the 
