Agile Project Engagement Roadmap

(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)

We recently had the disconcerting experience of having a client cancel our engagement because they'd felt that we weren't being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.

In our practice we typically combine a discovery phase and a prototyping analysis and design phase. What some people in the agile world might call iteration zero. For our client this discovery seemed open ended and they didn't have a clear understanding of how it fit into the project as a whole. This was a communication failure on our part. The process of discovery can indeed feel open-ended as it is the very nature of discovery to explore the domain of the business opportunity in an open way. The purpose of this "openness" is to find the appropriate scope, workflow, practical boundaries, and hidden benefits in an exploratory and visual manner.

The primary advantage of doing this work at a high level early on in the process is that it is much easier and cost-effective to identify boundaries and priorities on a whiteboard rather than during the construction phase or even during prototyping. We should have done a better job explaining this prior to our first discovering meeting which might have helped our client better understand our process and purpose. We also never really established a timeline beyond having one or more discovery meetings which may have added to their confusion.








Let's chalk this up to another lesson on the importance of managing client expectations.

Managing "Leaderful" Groups

In agile development circles self-organizing teams are all the rage nowadays. And I often hear people bemoaning the "evil managers". And no doubt in many circumstances and organizations there is real work to do here and real dysfunction to resolve. But I'm less concerned with the analysis of what's wrong and more concerned with what can we do differently and better. IE: How can we develop the skills necessary to practice effective self-organization.

So what does it mean to be a participant in a "leaderful" group?

The implication of "leaderful" is that many or most of the people in the group are exercising leadership. It seems that leadership is necessary, humans can't engage in group activity successfully without leadership. Successful group action always requires leadership and leaders. Someone, at least one person, must think about the effort as a whole and not only about her or his individual role in it in order for the group effort to succeed. A group can have more than one leader, but must have at least one to function successfully. Leadership is thinking about the well-being of the group as a whole as well as that of the individual group members. The essential commitment of a leader is to see to it that everything goes well.

I assume that leadership is an inherent capacity of every person and that leadership is not a "special" role or activity only for "special" people. The skills of successful leadership can be taught, learned, mastered, and practiced.

Further, I assume that people are fundamentally peers and that we are all doing the very best that we can at the moment. So the question becomes how do we reconcile assuming leadership with our peers? And how to we support each other in developing our leadership skills together?

More on this later...

Managing Leaderful Groups: Radical Transparency and the Paradox of Facilitated Self-Organization

Recently I've been working on my presentation for the West Coast scrum exchange in September. I thought it might be useful to share some of my ideas here to help clarify my thoughts. I've been using MindManager from Mindjet Software, and finding it quite useful for displaying the relationship between these various concepts.

What I'm hoping to do in this blog and in my sessions is to present a mix of theory, skills, and best practices that will allow you to come away with a sense of inquiry and a framework for ongoing self-improvement in this area. When were done:

• you'll have more fluency in skills including this domain in your thinking about your teams and work life
• you'll be better equipped to understand and intervene in your real-world work settings
• you'll have a list of practical next steps to try and skills to improve
• you'll have had fun

I'll be providing more detail in future installments.