Today is planning day for our largest team. After an interesting Sprint Review in the lab, we retired to the larger training room for the Sprint Retrospective.
The feel in the room was largely up-beat but had some unspoken tension. I shifted gears quickly to start different than planned. I asked that we go around the room and each member give two statments:
- Give one word that summarizes this sprint for you.
- Describe your passion about this sprint, team, project or company.
The one-word summaries were balanced between words like “progress” or “satisfaction” and “frustrated” or “bottleneck.” (Ah, the tension comes out.) This was reasonable given that not all the stories were completed this sprint.
The passion statements were great! They ranged from love of creating new technology to the joy of shipping actual product. We all learned interesting things about each other.
And the tension was over. Just like that, it was time to dig deeper into the sprint with clear heads and a forward view established as a great foundation for the meeting.
Personal Trill
My personal moment of happiness came during the expressions of passion. Two engineers spoke of the team’s effectiveness in powerful terms. To paraphrase:
The is the most productive team I have ever worked with in my entire career.
I didn’t think I would ever enjoy working on a team larger than 3 or 4 people, but this experience shows otherwise.
What a great team to work with!
I wrote up a brief summary of my presentation experience at the PhxSUG Meeting. Rather than repeat it here, go to the story on the group’s website for a read and comment if you like.
Let me just repeat that the meeting was an awesome way to spend an evening. Great discussions and smart people willing to talk about their experiences with Scrum.
A few weeks ago, lying in bed, waiting for my mind to turn off, my thoughts carried me to think about an Agile enterprise. What would be important? What would it look and feel like? A diagram of concepts formed to define the general areas of focus for an Agile enterprise. The next day I excitedly documented my thoughts over lunch.
A Holistic Enterprise View
The whole enterprise can be thought of as a circle. This circle is divided into three areas of focus. These three areas are almost never equal and will vary based on size, age and needs of the enterprise. Yet all three are present, if sometimes neglected in turn. The picture is like this:
Work
This is what the enterprise does, what it is paid for. Work is the product and all the production performed to create the product, tangible or digital. Work is the sum of the actions, the designing, writing, testing, coding, speaking, drawing, etc. that create what the customers buy. This is the highest focus of the enterprise and rightfully so, for without this, the enterprise cannot sustain itself.
Information
This segment of the circle represents the data or artifacts either produced or needed to do the Work. This is be source code, documentation of all types, emails, invoices, meetings, logs, procedures, accounts payable or receivable, etc. All enterprises large or small have and produce this data which must flow efficiently for the enterprise to do well.
People
This third segment represents the people and their interactions as they do the Work. This is management, hierarchy, social behavior, teamwork, conflict, collaboration, politics, disagreement, personality, etc. In order to accomplish the Work, people must communicate and interact. It is a huge, yet intangible, component of the enterprise.
Focus Areas
Each of these three areas, Work, Information and People, must function together. Work is always there, it is the reason for existing. When a company first starts it may be only one person or perhaps a few more. In such a situation the Work dominates all thought and effort. This is OK because a small group can usually move Information quickly and get along well as People. As an enterprise grows, difficulties within the Information and People areas more significantly impact the Work. From cultural habit, the enterprise will want to continue to focus on the Work but there must be people designated to prevent neglect in the other two areas.
- How long does it take for a developer to learn about a field problem in a product? The answer to this question is one measure of how will the Information area is doing.
- Does a person on the low end of the hierarchy feel safe to tell his supervisor or even division manager about a problem? This is a check on the People part of the enterprise.
- When the lab needs new equipment, how hard is it to get? This can touch on both Information (purchasing procedures and documents, etc.) and People (asking the manger to change the budget).
Keeping these three areas balanced according to the current needs of the enterprise is the primary function of mangers. They have the authority, position and mandate to ensure that the Work does not suffer because of neglect with the Information and the People. A great enterprise, dare I say an Agile enterprise, makes sure the Information moves quickly to the right place at the right time and that the People are interacting in high performance!
A Holistic Team View
This discussion started with a view to the enterprise but let us conclude by boiling it down to the Agile team. What do these three areas of focus look like when we use them to view a small working group?
- The Product Owner pushes Information flow about what the Work should be. Features, progress, vision and direction are controlled by Information in and out of the team.
- The ScrumMaster focuses largely on the People part of the team. He helps them resolve conflicts to create constructive outcomes. He creates environments in and out of the team that allows for trust and truth to be visible.
- The Team of developers focus on the Work, the product and the components that make it. With the Product Owner providing Information direction and the ScrumMaster maintaining a People friendly environment, the Work gets all the attention it needs for high quality and speedy production!
Note that each of the Agile team roles must keep the whole circle in mind and overlap, for all three areas are important. But each role as the area on which they focus the most.
For me the point of this view is simply another way to look at enterprises and teams. For me it brings more clarity to my roles as ScrumMaster and Agile Coach. Us it as a tool help you think about where you are and where you can create more value for your enterprise and team! Let me know what you think about it. I’d love to learn more!
I will be leading the presentation and discussion at the Phoenix Scrum User’s Group Meeting on Thursday, December 10, 2009.
Come join us for free food and great discussion about the Product Owner role!
Recently a discussion kicked up in Twitter about picking the one, key Agile practice. Obviously the answer can vary by situation, but the consensus I saw settled on the retrospective as the answer. Declan Whelan, in reply to Esther Derby, seemed to say it best:
I fully agree that retrospectives are the one powerful Agile practice to do if no others are yet implemented. I posted:
As I posted that brief message, I knew a blog post was needed to fully explain the strong statement.
Getting To Retrospective
The team had been doing “Scrum” for some weeks. I put Scrum in quotes because we really were not doing enough of the practices to use the term. Key members of this team and engineering management were not fully committed to Agile and Scrum. We were adopting practices slowly, as the acceptance of these key players allowed. We were doing:
- Weekly Sprints
- Weekly planning meetings
- Daily team status meetings, like a daily Scrum
- Using a team board with tasks
I had been requesting that we start doing retrospectives, even just do one to try it out. The biggest objection was the perception that it would be a waste of time on a “feel good” measure of little value. Percistent discussion and pointing out the well known desire to gather “lessons learned” finally prevailed. We scheduled one retrospective as a test. Maybe they just wanted to stop me asking. Whatever works, right?
The Culture
Prior to beginning our migration to Scrum, this team had a very traditional structure. A brilliant engineer was the Team Lead. He determined tasks for each of the team members. As we started doing sprints and team level planning, this lead continued the practice of defining tasks for each team member. We shifted to emphasizing that each team member needed to accept the suggested tasks. The reality remained that the Team Lead was determining the work of the team. (This practice was not Scrum, nor Agile. A dicussion of the value of such a slow shift to Scrum is another blog post. Or an essay!)
Several members of the development team were quiet. When discussing development one-on-one, they had great ideas and interesting things to say. When in the team meetings, they were largely silent and simply agreed with the more dominate personalities in the group.
The Setup
I chose our Training Room as the venue for the retrospective. This is also the same room where sprint planning meetings were held. Usually the room has four tables pushed together in the middle of the room to form one large table with 12-14 chairs around it. For most meetings this arrangement is appropriate but for others, it is not conducive to the meeting goals. (See http://blog.dayleyagile.com/2009/02/23/the-real-elephant-in-the-room/)
I split the tables appart, pushing them out to the edges of the room with the chairs lining three sides of the open space in the middle. The team board showing the task cards for the sprint just ended was positioned at the front on the wide marker boards, now erased and ready for writing. Sticky notes and pens were liberally sprinkled around the room for attendee use during the meeting.
The Meeting
During the meeting several notable things occurred.
- As attendees arrived they made comments about the organization of the room. Some were quizical, some were intregued. Two who brought notebook computers were unhappy at the lack of a table for thier electronic distractions.
- I asked each attendee to state what value they though they could get out to the meeting. Their responses were interesting. More important was getting each of them to talk so each would be more likely to speak up during the meeting.
- Each was asked to write sticky notes of what went well and what could be improved. This minimized the effect of dominating personalities and ensured that everone had the opportunity to contribute.
- Dot voting with performed to find the top improvements to work on. The Team Lead was particularly irritated that his three dots were not enough to force his desired improvements to the top of the list.
Immediate Changes
As I think about it today, this retrospective was not particularly effective for the practical work of the project. We did not even execute well on the choosen top improvements. The team member interaction started changing from that day forward.
- Everyone contributed at a team meeting, maybe for the first time. And it was not just the individual answer at the beginning, though I’m sure that opened the door. Every person provided sticky notes and comments throughout the meeting.
- Several times comments along the lines of “I didn’t know you thought that” were heard. The following planning meeting that afternoon was more lively than ever.
- Right there, in the meeting, the Team Lead role began to be absorbed into the team. This was difficult for the dominate personalities to take but the “human side” of the team started forming in a positive way.
Retrospective Power
As time went by, this team began to gel further. Participation in the meetings and with each other increased. The team unified further, more easily able to request changes from the larger organization. We also had serveral meetings that dove to the heart of individual difficulties, something not possible without higher levels of trust.
Several of the dominate personalities eventually left the company, perhaps in part as a side effect of at more egalitarian team environment. We continued to have retrospectives and attempted to apply the actions to improve our work and team. This team eventually produced the product and has now moved on, mostly joining into a team designing our next generation project. Retrospectives are a key part of the work and we never skip them, ever.
If you are doing a slow adoption of Agile practices and must pick only one practice, do retrospectives. Do them regularly and with serious attention. Daily meetings, sprints and team planning are powerful and look easier to start doing. Real change on with the team’s human dynamics really happen when the retrospective becomes part of your habitual practice.
Just a quick follow-up to my previous post.
The videos of the Developer Ignite 2 presentations have been posted. Watch the video of my presentation, titled “The True Measure of Agile,” and tell me what you think!
Abstract: The Agile wave is washing over the software development world and lapping at the shores of all creative endeavors. There are buzzwords, expensive software and training consultants a-plenty! What does it really mean to be Agile, with a capital “A”? If you have daily stand-up meetings and iterations, are you Agile or just covering old ways in trendy veneer. Iterations or not, you are Agile ONLY if your actions support the principles of the Agile Manifesto. Let’s take a quick look at the practical implications of THE yard stick of Agility. If your actions support this powerful statement of human interaction, you are Agile, even if your daily “stand up” involves chairs!
Don’t miss the other presentations too. The introduction speech is a good place to start.
Last night I presented at Developer Ignite 2. What a great experience! The friendly energy from the audience was powerfully supportive. The organizers had everything smooth and rolling, with excellent after event food.
The True Measure of Agile
I’m passionate about Agile and the power it brings to the people who apply it as intended. I’m also frustrated by strong evidence that many who speak the words of Agile development are only wrapping the same old practices in buzz. This is very bad for Agile and developers everywhere. So many times I’ve talked to engineers who “did Agile” or “did Scrum” and then proceed to describe a broken and painful experience of micro-management or loosely controlled chaos to failure. Coaching someone back from such a false agile implementation is often harder than pulling them out of waterfall.
The goal of my presentation was to point people back to the Agile Manifesto, to consider that there are meanings and values behind those words. Pick a framework, like Scrum or XP. Combine with practices like TDD and continuous integration. Do your “stand-up” meeting sitting down if you want. But make sure you check against the Agile Manifesto to keep driving to what Agile really means. That if those values are promoted by what you are doing, whatever it is, you are on the “true Agile” path.
My slides are available below for download and reuse. Because the Ignite format allows only 15 seconds per non-stop slide, there are few words, if any, on most of them. Perhaps you will find better words than mine to fill in! Let me know what you think of the message you get from them. The video will be posted soon at the event web page. Then you can compare what you thought to what I said.
- Download presentation as an ODP. (Open Document Presentation format, as with OpenOffice.org Impress)
- Download presentation as a PDF.
What I Learned
All of the presentations were great! A few points that stood out for me were:
- Tomasz Stechly (@tstechly) introduced me to the concept and benefits of immutable code. I’m now sorry to say it’s not a technique I have looked into very much.
- Derek Neighbors (@dneighbors) highlighted that we have too much information to slog through every day and that geo-location is one of the ways we can filter the flood to get at what is relevant where we are standing right now.
- Leo Godin (@leogodin217) re-enforced many of the things I read about getting to done and giving what the customer wants, a solution.
- Clayton Lengel-Zigich (@claytonlz) told 10 fables from Aesop and applied each of them to software development, including pair programming and TDD!
All of the presentations were great! I said that already and I’ll say it again, if anyone asks. Such talent in the Phoenix area!
Thank You
I give thanks to everyone who sponsored, organized, promoted and spoke. Especially I thank the audience for an awesome experience!
It’s been more than a month since updating here. I have been very busy and the blog plays second fiddle to many other things. This is also a “lazy” blog post. So much has happened or is going on I’m going to do a “flash-back episode” to catch things up.
Certified Scrum Practitioner
The end of September my application for Certified Scrum Practitioner was approved! How I could have been quiet about that I don’t know. The process was interesting. My first submission draft resulted in some requests for additional information. The requests were spot on, pointing out weaknesses and missing information. I was very glad for the review and extra work.
Approval took around two months. I was disappointed and worried about this slow turn-around. Of course, this was also the time of the recent tumult when Ken Schwaber and Jim Cundiff left the Scrum Alliance. Maybe that had an effect on the processing time.
Gaining the level of CSP had been helpful with my work. A few skeptics who actually know little of Scrum or Agile have expressed some additional interest after learning of the new level. Some seem to take me a bit more seriously. I see this as a positive benefit, but a minor one. Continuing the learning is more important to me.
PhxSUG Topic Tables
October 21st the Phoenix Scrum User’s Group had our monthly meeting. This time we concentrated on drawing for ideas from each other. We declared the event “Topic Tables” to have multiple discussions at once around various topics.
After we wrote suggested topics, we voted on them as a group. The four highest vote winners were distributed teams, integration of Scrum and traditional project management, calculation and use of velocity measurement and measuring performance of team members. I found it to be a fun and interesting way to do the meeting. It allowed for both learning and getting to know new people.
Ignite Phoenix 5
I posted earlier about my involvement with the crew of volunteers working on Ignite Phoenix events. Last week Ignite Phoenix 5 went off so smoothly, I still can’t believe the lack of drama for us the organizers. I love the Phoenix area and the great people on the team and that attend our awesome events!
Local ScrumMaster Discussions
I have been enjoying more interaction with local ScrumMasters and Agile practitioners. In particular, I enjoyed a recent discussion with Chris Young, ScrumMaster at Integrum Technologies. He has some great ideas and questions around working with small teams and handling the Product Backlog. The contrast to the large teams I am currently working with was very interesting. I hope to do some story workshop study with him very soon.
Developer Ignite 2
While I have worked on organizing Ignite events, I have never presented at one. A few weeks ago I submitted a topic for Developer Ignite 2. Intel has a significant presence in the Phoenix area. They have taken up to sponsoring an Ignite event centered around software development topics. My submitted topic is “The True Measure of Agile,” which was accepted for presentation! The event will take place tomorrow, on the evening of November 11th. I have been practicing my presentation as much as possible. 20 slides in 5 minutes without stopping is not easy to work in! Certainly forces focus on the core message. We’ll see how I do tomorrow.
My desire is to reveal the need to work toward the values expressed in the Agile Manifesto. That whatever framework or practices you use, it’s not Agile unless these values are supported. I’ll find out if I can do that in only 5 minutes!
We had a great Phoenix Scrum User’s Group meeting last week. Ron Jeffries and Chet Hendrickson were in the valley presenting a ScrumMaster training class. They kindly agreed to come speak to us one evening.
I reported my impressions and notes of the meeting on the group website. Head over there to see what I learned about agile developer excellence and Scrum developer certification possibilities.
In a previous post on volunteering, I metioned my work with Ignite Phoenix. It is a powerful force for creativity, energy and bringing communities together.
I attended Ignite Phoenix 1 more than a year ago. I was blown away by the willingness of people to stand up and talk about thier passion, the support from the audience and the creative minds connecting. When Jeff Moriarty and Roger Williams asked for volunteers to organize the next one, I jumped at the opportunity. I’ve been working the events ever since.
My Experience
Have you ever had a great planning meeting? One where everyone is at least supporting the discussions and when innovative and powerful ideas just seem to flow? Have you seen a speech or concert or movie that left you moved, passionate and uplifted? Fireworks in your head as the passionate presentation awakens power, connections and creativity in your own mind. This is Ignite Phoenix for me, for 18, five-minute presentations in a row. A brainstorming session of 550+ people led by 18 presenters with passion!
OK, so maybe it’s not directly Agile or Scrum related, but it is powerful. It recharges me to work with a fabulous “naturally agile” team. And the power of team building, on a huge scale, is on display. I love it!
The Points
- If you have passion to present, please submit your idea by Friday, October 2nd.
- If you are in the Phoenix, Arizona area on November 3rd, you should be at Ignite Phoenix 5.
- We’ll be at The Tempe Center for the Arts in the 600-seat theater. Watch the web site for updates on ticket availability.
