Want To Be Agile? Stop Doing “Projects.”

On Feb 9, 2013, at 9:57 PM, someone wrote:

Now….did you agree that there is ‘some stuff’ that needs to be done before sprinting?

No, I didn’t agree with that. Give me a product vision, a small cross-functional self-organizing team, a team room, some Post It notes, and a MacBook and we’ll get you some kind of working, tested product in two weeks. Actually we can borrow the Post Its and MacBook from somewhere. The other stuff (a fully-refined Product Backlog, complete environment set up, release plan, budget projections, market analysis, etc.) is nice to have, but not essential to start learning through empirical feedback. This is true even for “big” products — we’ll learn more about how many teams we might eventually need by starting with one team. Start small does not equal end small, though it’s also possible we’ll learn our one good team in one room gets more done than 20 mediocre geographically dispersed teams would have anyway.

This is unconventional, probably offends PMBOK* enthusiasts. The organizations that learn it sooner will be the quicker ones to discover their users’ real needs.

The organization may say it needs all kinds of project initiation activities, to accommodate people’s comfort, just as my daughter may need me to check under her bed for monsters.** So as a practical matter we may need to appease those people. This doesn’t mean there really were monsters under the bed.

“Project” and “project execution” are 20th Century concepts, perhaps useful for building skyscrapers and stuff with huge startup costs and exponential cost of change curves. But an impediment when it comes to Agile product development.


* The “Guide to the Project Manager’s Body of Knowledge” is a compendium of obsolete management techniques, updated every year by the Project Management Institute with more obsolete techniques.  Agilists know there are really only two misconceptions in “Project Management”: projects, and management.

** Hypothetical analogy. She doesn’t actually have me do this.

Posted under Uncategorized

This post was written by admin on February 10, 2013

Effort Estimation and Story Points Demystified

I recently worked with some teams in India that were obsessed with effort estimation.  It turned out their real problem wasn’t estimation, it was keeping the product in a properly tested, shippable state all the time — the basic requirement of Scrum.  If the product is always shippable, and the user stories are always small, and the Product Owner is always prioritizing, we can always ship a product with the important stuff in it.  If we get some estimates wrong, it just means we’ll omit the less important features.  This isn’t a perfect situation, but it’s much better than what most companies do: ship late, or ship untested.

Agile teams generally use relative estimation approaches such as story points, sometimes a Fibonacci scale, sometimes an exponential scale.  To learn how, watch this example of a Backlog Grooming Meeting.  Note that the Scrum team does not pay much attention to the points during the example Sprint Planning Meeting.  They are mostly to help the Product Owner make forecasts.


Posted under Agile Methodology, Scrum, Uncategorized

This post was written by admin on January 9, 2013

Scrum Reference Card now available in English and Spanish

The English version of Michael James’s famous Scrum Reference Card has been downloaded over 20,000 times.  A Spanish Scrum Reference Card is now also available, thanks to Martin Alaimo.  Reference Card de Scrum ahora también en español!

Spanish Scrum Reference CardFlag of Spain

Posted under Uncategorized

This post was written by admin on January 8, 2013

Playing it SAFe, Can a Large Organization Become Agile Without Changing Anything?

We’ve noticed someone selling a prescriptive approach to large scale Agile that actually appears to be 80% waterfall.  An 80/20 waterfall/agile hybrid approach may be a positive step, but we’re concerned that this scaled agile framework confuses people about what a truly Agile approach to large scale development would be.
Let’s examine some principles from the Agile Manifesto:
  • Business people and developers must work together daily throughout the project.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
On the other hand, the easy, safe prescription for scaling seems to deliberately institutionalize some bad ideas we usually call impediments:
  • A three layer stack with proxy Product Owners in the bottom layer, enmeshed in coding teams.  Somewhere above the pseudo-Product Owners, other silos contain the stuff we usually consider Product Owner work: vision, product management, release management, portfolio management.  In our experience it’s better for self-organizing teams to work directly with the *real* decision makers responsible for the vision as it emerges.  The Scrum Product Owner was never supposed to be an artificially elevated middle manager.  According to Kent Beck, the first known XP project failed because the “Goal Donor” was not the “Gold Owner.” We want regular face to face contact between business decision makers and development teams so all learn from each other.
  • Teams contain “Developers & Testers” but UX, architecture, integration (by the “System Team”), and “release train engineering” occur elsewhere.  In Scrum, these are team responsibilities, so we want truly cross-functional teams, usually with business requirements experts, UI/UX designers, etc. right on the teams.  Scrum encourages a rigorous definition of done.  Teams will be more Agile if they learn to integrate their work with other teams. This will be difficult at scale, but coordination roles only make this worse.
  • Somewhere up in the whipped cream layer of this cake we find czars such as the “Enterprise Architect” working on “Architectural Epics” guaranteed to lead to architectural bloat.  I assume this was created to appease senior technical guys who have grown rusty at everything but PowerPoint.  One place I worked with found their (waterfall era) Architecture Center Of Excellence ivory tower to be such a huge impediment they disbanded it and put the architects right on Scrum development teams, right in the team rooms.  An assigned “architect” role is utterly incompatible with the Agile principle “The best architectures, requirements, and designs emerge from self-organizing teams.”  Scrum teams are responsible for the design of the software they build.  If we must use multiple teams on one product/portfolio and we believe in team self organization, ScrumMasters must create environments that encourage teams to coordinate with each other through communities of practice, not implementation czars.
The 20% of this that’s Agile is the stuff that’s relatively easy to change in an organization: putting testers on the teams (except not integration testers evidently), working in iterations, acknowledging that architecture will evolve, and co-opting (occasionally abusing) Agile jargon.  Maybe a couple steps forward for some orgs, but far from ideal.  I think it will appeal to companies that are concerned with keeping cozy spots for everyone, avoiding the uncomfortable ambiguity and uncertainty where real breakthroughs occur.

Posted under Agile Methodology, Scrum, Uncategorized

This post was written by admin on January 2, 2013

Community Development – A coding community

I work mostly with software teams in large organizations. One things I’ve noticed is that the vast majority (all?) tend to work in a very siloed manner. Whether by design or default, the good news is that this serves to insulate each of the teams from unwanted changes to the systems and infrastructure. But it also cause issues, because it is highly inefficient. Not only are the administrative overheads impacted, IP is not shared and expertise is not leveraged. Centralizing and consolidating IT software assets is the foundation upon which organizations can implement a robust coding community that promotes collaboration and sharing across enterprise teams.

A coding community relies upon the implementation of a community architecture to provide the facilities for data sharing, structured data, and enabling communities to work together in the development and delivery of software applications. Key aspects of the Community include the following:

• The Community must include social forums for ad-hoc collaboration between distributed team members. Such forums might include wiki-based knowledgebase containing a central and searchable repository of comments, code snippets, libraries and other valuable assets
• Team members from any part of the organization can benefit from enhanced visibility and search across the enterprise. Subject to the security constraints of the specific business, the more visibility given to developers, the more access to those valuable IT assets is provided, the more productive those developers can be. Sharing in a safe and controlled environment is a huge boost to productivity.
• Just like any other part of an enterprises’ IT environment, comprehensive governance is a necessity. The community architecture that is put in place to foster re-use must also reflect the governance and security mandates of the individual enterprise.
• To the degree possible, it is often useful to enhance third-party collaboration in the coding community. This extends re-use and cooperation beyond the firewall.

Done well, a development community can help a disparate, fractured and distributed staff in the development organization find common architectural foundations, share best practices, communicate more effectively. Outside of the development organization, a Community Architecture can break down the barriers and bridge the gaps between non-technical business people and the developer community.

Here’s an interesting White Paper on Social Coding.

Posted under Uncategorized

This post was written by admin on January 3, 2012

ScrumMaster Checklist and Scrum Reference Card

An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.

But if you can envision a team that has a great time accomplishing things you didn’t previously consider possible, within a transformed organization — consider being a great ScrumMaster.

Check out the ScrumMaster Checklist written by Michael James. It will help you gauge the progress of your agile teams and help you answer questions like:
• How is my Product Owner doing?
• How is my team doing?
• How are our engineering practices doing?
• How is the organization doing?

To learn about Scrum from entertaining cartoon characters, see the Scrum Training Series.

Michael has also written the Scrum Reference Card, a valuable reference document for anyone practicing Scrum or other Agile disciplines. (http://ScrumReferenceCard.com)

Posted under Uncategorized

This post was written by admin on November 19, 2010

Getting Down to Business with Games

Over at InfoQ, Deborah Hartmann Preuss reports on the values of games for teaching the principles of Scrum. If youÂ’ve ever attended a Certified ScrumMaster or Product Owner course, chances are your instructor led the group to a deeper understanding of Scrum and agile principles by playing a game or utilizing an interactive exercise. ItÂ’s an effective strategy for communicating difficult-to-grasp ideas in a fun and memorable way and itÂ’s becoming increasingly common for agile education.

IÂ’ve played a number of games over the course of my agile and Scrum education. If youÂ’re responsible for teaching your team or others in your organization, here are a few helpful links thatÂ’ll give you some proof that games are, in fact, valuable and will provide a few ideas for games to try.

HereÂ’s CST Kane Mar on the Ball Point Game, which he learned from Boris Gloger: http://blogs.danube.com/scrum-trainers-gathering-24-the-ball-point-game

And hereÂ’s Katie Playfair of Danube Technologies arguing for the relevance of game-playing: http://blogs.danube.com/the-value-of-games-ingraining-the-intangible-in-an-audience

Posted under Uncategorized

This post was written by admin on December 22, 2009

Agile Team Lead?

Mike Bria recently posted a story on InfoQ discussing how a group of agilistas are arguing for the creation of a new role within agile and Scrum teams called the “agile team lead,” designed to effectively replace the ScrumMaster and Project Manager positions. For purists, it’s hard not to be skeptical, especially considering the delicate balance of authority and responsibility that marks the composition of Scrum teams. But for the sake of entertaining the idea, the following criteria summarize the group’s ideas about the duties that agile team leadership entails:

  • “Continuous Leadership
    Understanding the team’s place in the organization’s goals, being a single point of leadership (for the team) and accountability (to stakeholders), building a “safe container” for the team to work within, growing trust and respect between team and stakeholders, and continuously improving team cohesion.
  • “Continuous Planning
    Ensuring the team become increasing capable of meeting their own established commitments, ensuring everything remain “big and visible”, manages metrics, making “the plan the bad guy” (as opposed to the people), and ensuring the “plan changes with demand/supply”.
  • “Continuous Execution
    “Monitoring/managing team velocity/throughput”, securing resources, removing and escalating blockages. Ultimately, “keeping flow, momentum and focus in the team”.
  • “Continuous Risk Reduction
    Identifying risks and making their “potential impacts big and visible to the right people”, ensuring risk reduction occurs, and quantifying risk management effectiveness.
  • “Continuous Improvement (Agile Coaching)
    Driving the “improvement of the overall Definition of Done“, sensing and drawing attention to performance breakdowns, facilitating team improvements in the right areas, and helping the team learn emerging practices from outside itself.”

Though several Scrum and agile practitioners have supported this idea, my favorite response belongs to CST Tobias Mayer, who states: “Creating a ‘role’ of team lead is the beginning of a slippery slope back to command and control, It is a cop-out, an excuse for not facing the real challenge of nurturing a leader-full team.”

I can’t help but agree. This role not only seems to disrupt the balance of power in Scrum and agile, but seems to be moving backwards—toward traditional management practices. I’m curious to know what you think. Would an agile team lead role solve problems at your organization or just create more? Let me know what you think in the comments.

Posted under Uncategorized

This post was written by admin on December 17, 2009

Lean Software

As I’ve discussed here before, Lean manufacturing, typified by Toyota and Honda’s production system of the 1980s, was one of the most influential precursors to agile development practices. Specifically, Lean’s emphasis on ongoing evaluation of the team’s performance, constant pursuit of process improvement, and continued waste elimination can be directly observed in agile’s tenets of incremental and iterative inspection and adaptation. Tony Baer, an analyst who covers agile, discussed how Lean has become a hot topic of discussion of late among the agile community. According to Baer’s post, this debate boils down to two arguments: “First is the contention that value stream analysis will add unnecessary bottlenecks, and second is that software development is a special case to which manufacturing metaphors do not apply.”

Baer’s take on these issues tends to align with my own thinking. Firstly, he acknowledges that it does seem a little contradictory for a development methodology that privileges a reactive approach to emerging conditions to place such an emphasis on value stream analysis. However, he still acknowledges the value of this kind of analysis. In the case of the latter argument, Baer cites a concern among developers that software development is categorically different from any other kind of construction or development process that occurs in the real world. Certainly, such criticisms are correct: Software development is not governed by a stable set of physical properties like, say, bridge building is. However, Lean’s values—as described above—are all applicable to project management, regardless of what is being produced. After all, Lean is essentially a philosophical approach, in which teams and organizations commit to continuous improvement—by reflecting on processes and taking whatever steps necessary to improve them.

Posted under Uncategorized

This post was written by admin on September 29, 2009

Tags: ,