Clayton Lengel-Zigich

WARNING: The following post talks about “commitments” and “planning” if your agile worldview finds these terms dangerous and unsafe, continue at your own risk. What is Commitment Driven Planning? Commitment Driven Planning (sometimes called Capacity Driven Planning) is a technique that lets a team determine how much work to bring into the sprint based on how much time they have to do said work. What do I need for Commitment Driven Planning?

Setup For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck. Setting Expectations At the heart of this retrospective exercise is defining expectations for yourself and your teammates. Start by explaining that on most teams, there are varying expectations. Some people expect different things from different people and from different roles. The exercise as described below is focused on a Scrum team, but the questions could be adapted for any team.

I was recently fortunate enough to attend the Culture Conference in both Philadelphia and Boston. Even more so, I was able to enjoy the company, conversation and new relationships as a member of the party bus that traveled between the two conferences. As we drove over the George Washington Bridge, I was having a conversation with Dan Mezick about the role of Agile Coaching in ethical billing and creating learning organizations.

Working software is the primary measure of progress. – Principles behind the Agile Manifesto Pixel perfect design mockups, UML diagrams, detailed user stories, automated tests, thousands of lines of code and hours of discussions. These are just a few examples of the endless amount of stuff we can spend time creating, tweaking, editing, testing and reviewing. However, nothing shows progress quite like working software. So what is working software?

Jenkins CI is a popular open source continuous integration server. I encourage teams to use continuous integration, however many teams setup the server, configure the automated e-mail blasts and think that’s all there is to it. Many teams don’t make the results of their builds part of an informative workspace. The team I’m currently working with fell into this trap and started having issues with failing builds going unnoticed. I looked around for some plugins and projects to help with this goal, but nothing quite met our needs.

Physical Boards Please I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it.

Here are the slides for my presentation at the May 2012 Phoenix Scrum User’s Group meeting. If you attended the meeting and have any further questions, please contact me, clayton@claytonlz.com. Retrospectives: Best Practices, Common Problems and New Ideas Retrospectives: Best Practices, Common Problems and New Ideas from Clayton Lengel-Zigich View more presentations from Clayton Lengel-Zigich.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. – Agile Principles Manager, Tear Down These Walls If you were tasked with designing a system that made spontaneous collaboration difficult, you couldn’t go wrong with the modern cube farm. Members of a “team” dispersed over an area of the office, isolated in their drab tchotchke ridden cubicles. Instant message, e-mail and chat might be great for passive communication, but when it comes to real collaboration, being physically present is essential.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. – Agile Principles Self-Organizing Allow the people doing the work to self-organize and discover the best implementation they can given what they know right now. Protect them from organizational politics and outside distractions, enable them to focus on the work at hand. Self-Directing While we encourage self-organization, we remember the need for direction.

Business people and developers must work together daily throughout the project. – Agile Principles Email is not Enough Working together involves more than exchanging e-mails about the software. It’s more than passive instant messenger conversations. It’s not reviewing a digital agile tool in isolation. Working together means collaborating, negotiating and exploring the software that is being built. Too Busy for Success? If you’re too busy to interact, fairly frequently, on a daily basis with the rest of the team, you’re too busy to enable product success.