Agile Methodology Understanding Agile Methodology

Posted under Uncategorized

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

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

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!

Posted under Uncategorized

Posted under Agile Methodology, Scrum, Uncategorized

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

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

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

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

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