I attended Agile Coach Camp United States (Twitter #ACCUS) this weekend. ACCUS is an open space, self organizing conference. I created a video to share the results of the open space topic I proposed, building Agile community in small cities:
[youtube=http://www.youtube.com/watch?v=0ZcjCyY9I6M]
Please feel free to comment on other ideas for building community, especially if you have tested those ideas and have learned from it.
Are you on a team where tasks seem to get started but not finished? Does the daily standup involve updates where individuals work on what seems like the same handful of tasks for multiple days?
Here’s a technique you can try for limiting work-in-progress. Instead of identifying task ownership whereby team members write their name on multiple task cards, ask each to use a single PostIt note with their name on it. Each person gets only one note with his or her name on it. Let’s face it, even if you have more than one task in the “In Progress” column, you can only work on one at a time. The sticky note is to be placed on the task that is being worked on at that moment. The note is moved throughout the day when changing tasks.
Here are some benefits of this approach:
Token to help address too much WIP
In addition to simply putting your name on a single sticky note, you could also capture data about context switching with this simple method. Write the date on your token. For that day, put a tally mark on the note each time the token moves from one task to another.
By using the date and tally marks on the card, you can get a sense for how much context switching is happening throughout the day. Perhaps thrashing is an impediment for your team. Of course, if you switch tasks six times and 5 tasks are completed, you probably don’t have a problem. If you switch six times and nothing gets to “Done,” there may be an impediment’s root cause to search for. Collect the notes throughout the iteration and look for trends in the data.
I hope you find this technique useful. Feel free to comment on the post.
I authored most of this on my flight from San Francisco back to Midway last night…my Southwest flight did not have wifi for me to post it, however.
It’s Friday night, and I’m traveling home from San Francisco where I had a great experience at the inaugural SFAgile conference.The conference had high quality speakers, most of the speakers were also able to stay for the duration of the two-day conference. Not only did I receive a lot of value from the formal sessions, the conversations outside of the sessions were particularly valuable(See note 1 below).
SF Agile was an intimate, single-track conference that covered a breadth of topics, including Lean Startup, Lean UX, Teams and Product Stewardship, an Innovation Game, escaping timeboxes (new term materialized: “neo-post-agile”)… And that was Day 1!
Day 2 had topics that included Agile Leadership, a panel discussion with audience-selected topics, lessons from Dr. Who, Coaching, the team/business bridge, and happiness. Although I neglected to put a mark on the “Value to Time Invested” retrospective chart (sorry Angeline), I will posthumously put it to “up and to the right,” which we learned at the conference is where all good data on a graph goes.
Each day culminated in a trip down Market street to Blu to socialize with other attendees. The conference’s size allowed for interaction with almost all of the attendees. This is the second conference this year that I have attended that had a single-track format( See Note 2 below). I think I am a fan of the format. The single-track format creates a shared context for all the attendees. During breaks and after the day’s formal activities, there is a common reference point that helps create cohesion as attendees can discuss a range of ideas presented throughout the day.
Thank you, thank you, thank you.
Thank you to all the sponsors for making the event very affordable for attendees.
Thank you for allowing me to share how lean principles and getting close to the customer and market were instrumental in shaping my path to being an entrepreneur.
Thank you Angeline and the rest of the folks who contributed to making this event a success. I hope to attend next year’s event.
For those of you who did not go to the conference, consider putting it on your calendar for next June.
Note 1. One example of the additional value was with Joshua Kerievsky’s who recommended the book The Secrets of Consulting by Gerald Weinberg, I actually had to put that book down to capture some of my reflections on the conference.
Note 2. KalamazooX was the other conference. That, too, was a valuable conference and I am way overdue to create a blog post about that. KalamazooX was a very nice one day conference focusing on the softer skills required in technology. Sorry Michael Eaton for the delay in writing about that conference. There was no flight home from Kalamazoo for me to draft it!
Picture this: You’re planning a sprint, going over stories in the Product Backlog, bringing high priority stories into the Sprint Backlog, and working to identify what is required to deliver the stories. The Product Owner is present, making sure that the team understands the acceptance criteria, and the ScrumMaster is facilitating the session, helping ensure that the team doesn’t overcommit. Things are moving along smoothly.
As the team begins to figure out what it takes to deliver a story, a team member says:
Some rights reserved by ginatrapani
“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the new programming language we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a developer follow the steps in the document and manually enter the result into the system we have to interface with.”
That would be absurd! No developer would ever utterer that in real life. The story can either get coded to meet the acceptance criteria within the desired timeframe, or it cannot.
Now, if you take that previous sentence and change it a little bit:
“Well, we can figure out the steps the system will have to perform to complete the business logic. We also know what data table the result needs to go into. The Product Owner really wants this feature, but we’re not too familiar with the automated testing framework we are using and it would take too much time to figure it out. For now, we will put the logical steps into a Word document and have a tester follow the steps in the document and manually enter the result into the test result matrix.”
Somehow, the “test” version of that paragraph isn’t only acceptable to a lot of teams, it’s incredibly common to hear. “We don’t have time to automate the tests.”
In reality, you don’t have time the luxury of not automating your tests. Manual testing isn’t sustainable; it is too expensive and it is too slow to execute all the logic present in your application. Because manual testing is not feasible, the buildup of untested code in your system present the biggest risk to almost any software development effort. (James Grenning recently articulated a strong case for why this is so at a recent Chicago Agile Project Leadership Network meeting.) That risk may not manifest itself today or tomorrow, but not too many versions down the road your team, your application, and your business is going to hit a brick wall of poor quality.
Automated testing cannot be optional. It’s the team’s responsibility to make sure that automated tests are being created. You don’t have to be perfect to get started; just start during your next Sprint. Next, inspect and adapt. Learn from others, get training, and make the investment. Perhaps you “complete” fewer features by not investing in automation, but remember… you would not call a story “done” if the code is not automated, so don’t call it “done” if the tests are not automated.
“If you don’t know where you are going, any road will get you there,” said Lewis Carroll. Not only does this statement apply to individuals, but also to teams. In either case, you might not like the destination when you get there.
Stephen Covey’s second habit is “Begin with the End in Mind”. Before you can effectively create the physical manifestation of the product you want to create or the team you want to be, you have to first create a mental representation of that end state.
One exercise he proposes for helping to clarify what is supremely important to you is to visualize your own funeral. When you visualize your family, friends, or coworkers speaking about you after you have passed, what would you want people to say? As helpful as this visualization exercise can be for individuals to recognize what is important in their lives, it is also important for teams to determine what is important to them.
If an article were written about your team and preserved for the future, what would you want people to know about your team, about how you treated each other, and the way you went about your work? To help determine what is important to your team, consider your team’s ultimate goal. What do you want people to say about you, your team, and your work. Consider your teammates, your Product Owner, your stakeholders, and your customers. What about your functional manager? Consider involving your stakeholder community in the discussion.
Going through such an exercise can result in identifying a common view of what the team wants to become and how they want to operate. Without agreement on what the team values, the urgent demands of the project can keep you from becoming the team you need to become. Symptoms of teams without a compass may be that your team becomes myopic, focused on creating features to the detriment of sustainable pace or maintainable code. Alternatively, your team could become paralyzed by analysis and architecture debates, not recognizing when the analysis is sufficient to allow it to move forward.
To create your team vision is to “begin with the end in mind.” It is more than an elevator statement that captures the 30-second pitch for your product, and it is also more than a list of user stories that you intend to complete within a particular timeframe. What you want to distill from this exercise is a set of principles that can inform the decisions that you and your team will have to make through the course of your work. Take the information you collect and use it to create a mission statement for your team. When creating your mission statement, ensure the involvement of all team members; perhaps have a facilitated discussion led by somebody from outside the team can help ensure that all voices are heard. As Mr. Covey puts it: “No involvement, no commitment.”
Make your mission statement visible in your team room, on its wiki, give printouts to each team member, and anywhere else you feel is appropriate. If somebody is violating the mission statement, inquire about the deviation and determine if the mission statement has become outdated or if the behavior is perhaps not correct. Include a review of the mission statement as part of your retrospective.
Remember, if you are on an team and don’t know where you are going, you won’t get anywhere you want to be. Keeping the end in mind and using the mission statement as a team compass can help the team stay on track toward its desired goal.
Proactively addressing risks is one of the major strengths of Agile methods. Not only do Agile teams have “spikes” to try to eliminate technical risks, but effective Agile teams have a mindset of eliminating a wide array of risks. Here are some examples of ways risk is proactively addressed in Agile environments:
If a technology approach is of concern, we do a design spike and find out quickly if the approach isn’t feasible.
In Scrum, the retrospective is an explicit opportunity to look for ways to continue to improve, not resting with “we’re good enough”.
The “test first” approach is a proactive approach to quality.*
If the budget gets cut, we have working software created, not merely the requirements document, design document, and a pile of untested code.
The description of “Be Proactive” in the 7 Habits is “Proactive people take responsibility for their own lives. They determine the agendas they will follow and choose how to respond to what happens to them.” I don’t think I’ve seen an Agile book put it more succinctly. This excerpt could easily be rewritten for Agile teams: “Proactive [agile teams] take responsibility for their own [work]. They determine the agendas they will follow and choose how to respond to what happens to them.”
The Agile Manifesto’s 12 Principles has three in particular that stand out to me as having proactive risk mitigation components to them. These three are:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
So, what do you do if you are on a team that has not embraced their responsibility to be proactive? Here are a couple of suggestions:
Consider whether or not your team has the trust necessary to be comfortable identifying risks. I suggest reading the book “Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators (J-B Lencioni Series)“. This book is a follow-up to the book “The Five Dysfunctions of a Team”. The “Overcoming….” book offers specific activities and suggestions that help address the dysfunctions identified in the earlier book.
Is the team able to communicate in a high bandwidth mode? If risks are getting lost in low-bandwidth communication, consider moving to a collocated room. Eric Landes authored a DevX article entitled “Team Rooms Breed Highly Productive Agile Software Development Teams“. FYI: You will have to register to read the article.
Model proactive behavior. One of the best ways to show that something is important is to do it yourself.
Encourage your teams to be more proactive about their work, and I believe you will find that good things follow.
*See the “Being Proactive – Getting to the Triangle of Happiness” blog about testing as it relates to happiness on a blog by Daniel Wintschel and humandoing software.
This blog introduces a concept that I will build on in subsequent entries.
Perhaps Stephen Covey’s most popular contribution to personal performance management is the concepts he shares in his book The 7 Habits of Highly Effective People. Long before I heard about Agile, I was part of a professional services company that had Franklin Planner training as standard training element for its employees. I still remember the instructor’s name, Rory Aplanap; a name like that is easy to remember. Rory taught the class with enthusiasm, articulating the principles and the practices that the 7 Habits book lays out. He also taught us how to use the Franklin Planner system to support the 7 Habits.
For those who are not familiar with the 7 Habits, they are:
I see some strong parallels between the 7 Habits and high performing Agile teams. Here is a quick preview of some of the correlations I will expand upon in future posts:
Be Proactive – Teams are responsible for themselves and their work. As one example, this behavior manifests itself in teams making iteration commitments in Scrum and team members stretching beyond their traditional roles to help realize that goal. Teams decide how they are going to function and how to respond to stimuli from both within and outside their team.
Begin with the End in Mind – This concept is present in planning that begins with a product vision, and is then unfolded to become releasable increments, stories and tasks. All this work takes place in the context of some shared vision that the team is working to bring into reality.
Put First Things First – We strive to ruthlessly prioritize, and to maximize the amount of work not done.
Think Win/Win – The objective is to find a path by which multiple parties meet their objectives. It is not about one side winning and the other losing.
Seek First to Understand, Then to Be Understood – For an Agile team, it is not about blindly following along in a task list that somebody has created for you; it’s about really understanding what is needed, and then sharing your perspective and concerns.
Synergize – Think about the collaboration between the Product Owner and the Team that results in a solution that is better than if the parties had worked independently.
Sharpen the Saw – This might be in the form of learning new engineering practices, having time to investigate a new and interesting technology, or simply celebrating as a team.
As I mentioned a the outset, this is simply an overview of the topic, and I will expand on it further in upcoming entries.
I believe that today’s team retrospective may have contributed a new term to the Agile lexicon: Rejactoring
While “refactoring” is the agile-embraced practice of improving the quality of the system without changing the system’s behavior, a “rejactoring” is a “refactoring” that “jacks up” the object of the refactor. When a refactoring goes bad, it becomes a “rejactoring.” Rejactoring the code results in systems breaking in unexpected ways and at inconvenient times.
Here are some suggestions on how to avoid rejactoring your code:
For further reading on refactoring, check out Martin Fowler‘s book, Refactoring: Improving the Design of Existing Code as well as the site Refactoring.com.
One of my teams been involved in a bit of a discussion as to whether or not defects in the product backlog should be sized using Story Points, just as we size stories. Mike Cohn has a very good blog about “Story Points for Bug Fixing.” As I read his post, I believe it is specific to the scenario where a team has inherited a set of defects from a prior release or a legacy product that they are going to attempt to work through in the midst of delivering new features. Mike’s recommendation is that defects be sized, much like stories would, and that the resulting completed work would count toward the team’s velocity. I agree with that approach. I believe the scenario that we’ve encountered is a different one, and thus a different approach may be more suitable. The scenario I would like to explore is one in which defects found in the current release’s earlier iterations. Should those defects be sized and be included in the team’s velocity?
Consider a scenario where the features set to be delivered consists of 100 points of work, and that the team’s average velocity is 20 point per iteration. The figure below shows what a release burndown might look like under these conditions. Prior to iteration 1, there are 100 points of work to do. At the end of iteration 1, we have completed 20 points of work with high quality and there are 80 points remaining. Finally, at the end of iteration 5 the backlog has been reduced to zero*. The burndown in this scenario is “Backlog Points Remaining after Iteration – Scenario 1”
This burndown shows the points remaining after each iteration is complete. Each iteration, the team completes 20 points of work on stories that are in the backlog.
In another scenario, we identify defects from earlier iterations, size them, and include them in the iteration’s velocity. So, in scenario 2, each iteration still shows a velocity of 20, but the burndown does not reach zero after the five iterations are complete.
This burndown shows the points remaining after each iteration is complete. Again, the team completes 20 points of work each iteration.
Without the proper visibility to the information feeding this chart, it appears that the product manager is growing the backlog. However, if you were to decompose the velocity into its constituent points (illustrated below), you see that in the second scenario the contribution of defects to the team’s velocity grows throughout the release cycle. The assumption that the effort put toward defects will grow is reasonable; if there are defects being introduced early on in the release and nothing changes to address the root cause, the defects will continue to be introduced and their contribution will become more and more significant. Without transparency to what made up the velocity, the team can feel that they have executed with their ‘expected velocity’ and the product owner can feel like she is getting asked to make unreasonable concessions due to quality problems. Do you think it is reasonable that the product owner would remove scope because the quality of earlier deliverables was not high?
This view shows the points that were dedicated to stories in the backlog compared to points assigned to defects.
So, what to do?
I do agree that bugs from prior releases should be sized by the team and prioritized by the product owner, much like a new story. In that case, defects from prior releases would be included in the velocity, and the product owner could determine what new features could be completed if work toward resolving legacy issues was suspended.
If defects introduced in earlier iterations are going to be fixed in subsequent iterations, their contribution to the team’s velocity should be made big and visible. Only if the information is visible will it get the proper attention so the team and product management can work to figure out the root cause of the defects. If the team is not going to make the effort put toward resolving defects visible, I would suggest that it would be best to not size the defects and to merely let the ongoing reduction in team velocity be the canary in the coal mine. Unlike the scenario that Mike spoke about, the team cannot reasonably suspend defect resolution to deliver additional features.
Lastly, if the team’s anticipated velocity includes an allocation to fixing defects that are yet to be introduced, this needs to be accounted for as part of release planning, as well.
Ultimately, it is critical to identify the root cause of the defects and to address the root cause. Without addressing the root cause, we are left with an ever-increasing allocation of time to resolving defects that we are introducing as we build new features.
Conclusion: Sizing defects that are introduced as part of the release that you are currently working on can produce a misleading velocity. If you do want to size defects and have them contribute toward the velocity, segregate the points from Defects and Stories so that the effort toward each becomes plainly visible.
Footnote:
*For the sake of illustration, I have simplified the scenario. Indeed, there is often some variability in velocity from one iteration to the next. This scenario also assumes that the product backlog is constant throughout the five iterations.
I realized that, for me, one of the most enjoyable aspects of being in the technology field is having the opportunity to exchange ideas with other technology professionals. A rich dialog with other professionals helps me become introduced to new ideas, new techniques, and possibilities that I may not have encountered had I simply relied on my own personal experiences. Networking is also a great recruiting tool to identify talented folks that you might want to join your company as openings are created.
I wanted to share just a few groups that I am personally aware of because I have attended.
This group was started as, and continues to be, an informal gathering to discuss Agile. Beyond that, there is no single focus or formal agenda. The meetings are typically on the first Monday of each month at 5:30 PM. For September, the meeting will be on the 13th of September due to the Labor Day holiday, but still at 5:30. We meet at Hacienda on Miami Street. The Michiana Agile Practitioners group resides on LinkedIn.
This user group, obviously focused on .NET, is currently in the process of planning a “Tech Fest” to be held on September 18th. The day will be broken into two tracks, one focused on development, and the other with a focus IT. You can view the agenda for Tech Fest on the MADNUG site. Press Ganey was generous and is going to host the tech fest in their training center.
Chicago Agile Project Manager MeetUp
If you’re up for a road trip, this MeetUp is worth it. Meeting in downtown Chicago at 5:30 Central, you can get most of the regular work day in and still make it to the meeting on time. The attendees typically have a broad range of experience with Agile, from “exploring” to people that many would consider “expert.” The meetings are held on a monthly basis, and the topics are advertised at least weeks ahead of time. The number of attendees is limited to 30, so an early RSVP is required. Most months, I attend with at least one other coworker or guest. Carpooling makes the drive go by quickly, and most times we are back to South Bend and off the toll road by 10:30. If you’re interested, feel free to contact me and join the carpool.
I used Google to look for additional groups, and pretty much came up empty. Are there other technology user groups that you are familiar with and would recommend?