Progress Principle

Adoption and acceptance of agile is always helped when teams begin to build and deliver working product in frequent intervals. In most cases, this is done by delivering a new product increment every iteration. What's interesting, is that delivering regularly to the Product Owner/Customer has been, in my experience, one of the best ways to circumvent resistance to making the change to agile methods. Here's some research published in the Harvard Business Review that supports this.

Team motivation - Daniel Pink on TED

We talk about motivation and motivating teams. This is worth watching - Daniel Pink on TED from 2009:

Life is not always what you think it is or works how we think it works. Pay attention to ROWE - results only work environment and the parts where he talks about autonomy, mastery & purpose versus the traditional carrot and stick.

Very surprising in some ways, but completely expected in other ways.

Multi-tasking - is it really this bad everywhere?

Multitasking is killing many of the projects I'm currently coaching. Team members literally have 3, 4 or even as many as 5 projects going at once. Teams are formed with multiple members, each on multiple projects. In almost every case, where there's heavy multi-tasking the teams choose to have their daily standup two times per week. Catch that - daily standup, only twice per week...

Embrace your circumstances

Ever notice how some people and some teams seem to thrive in adversity. They seem to be at their best - it's like they're waiting for the chance to show everyone just how strong, how capable they are when the going gets rough. Last year this hit home for me during the NFL season. The New England Patriots, in particular Tom Brady their quarterback, have an extraordinary winning percentage in extreme cold weather conditions.

I'm tired of hearing: "You're not agile if you aren't doing ..."

I hear this all the time and it drives me crazy: "you're not agile if you aren't doing <name a practice>." Just fill in the blank - automated tests, user stories, continuous integration, co-location, product owner in the room, and on and on. At a Certified Scrum Course taught by Craig Larman he used the term "perfection goal." That phrase stuck with me partially because it speaks to a future state where a high-performing team is adhering to the key agile principles and practices. Here's the deal. You don't have to do every best practice and you don't have to adhere to every principle to start being agile. You have to start somewhere - the more you can start with the better, but some aspects can evolve over time.

Discipline & Formality - is there a difference?

When I'm mentoring teams for the first time on agile methods and practices, as an introductory discussion, I sometimes ask team members to tell me what they know about agile development or what they've heard about it. If I'm not getting any negative perceptions I encourage them by asking that they tell me what they've heard regarding challenges in using agile or to describe things they've heard that don' t work, or even better how agile won't work in their environment.  Some of the typical responses are:

• Agile means no documentation
• In agile you can do what you want however you want
• It's about cowboy coding & hacking
• No reviews
• You change requirements whenever you want and as often as you want
• We can't use agile, because the product owner will change the requirements and if we don't have a signed off requirements document before we begin our design and planning we'll never finish on time

These negative answers speak to a perception that agile methods are both informal & undisciplined in their approach to software development. 

Reflection

This is Part 5 - the final part of the series

Part 1     Part 2     Part 3    Part 4     Part 5

Well this timing worked out just perfectly. A new year is here; time for reflection which is the last topic in this series on what it takes to improve performance of individuals and teams.

In the previous parts of this series I've used sports and music to evaluate lessons learned on improving  performance. Continuing with that theme, reflection occurs as a natural part of the process of learning. Reflection is also a natural part of agile development and agile coaching. In fact it is the primary way we improve our performance. Inspect and adapt.