I just finished the book "A Leader's Guide to Radical Management". This book argues for expanding and implementing iterative and transparent management techniques across the entire organization. So, it is one of any number of methodologies and philosophies that argue for proliferating the principles of contemporary software development techniques found in Agile Scrum to a broader application.
If you are familiar with Agile/Scrum, much of the "radical" techniques will be very familiar. This is especially true about the long list of practices that are suggested at the end of each chapter. Nothing really new here.
The main premise of the book is about identifying clients and focusing on pleasing them. Clients do not have to be external customers but are also internal groups or departments that consume the output of another group or team.
There is lots of good wisdom about team leadership, transparency and client-focused operational techniques that is communicated through anecdotal stories throughout.
Overall a decent read, more interesting if you are not at all familiar with the concepts.
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Saturday, March 12, 2011
Saturday, September 12, 2009
Agile Update and New Blog Discoveries
Another second Friday, another completed Iteration. This particular Iteration had a lot of carryover from the last one. Many stories were code complete but were not accepted by stakeholders due to lack of availabilty. A lot of those were accepted. Most of the stories that are required for the upcoming release are accepted or will be early Monday.
Next Iteration will be a "Qualification Iteration". This means that there will be little or no new features added during the next 2 weeks while we submit release candidate builds to Customer Support to run real-world tests. The goal is to have a real RC1 by Wednesday. We may also do a late night Wednesday or Thursday night and provide dinner to the Support group and Development to encourage a focused testing window of 2-3 hours so we can try to flush out regression defects sooner rather than later.
Our plan is to do Qual Iterations at the end of each release. A typical release cycle will be some number of normal scrum cycles where we accept a set of stories and defects. After all the feature-adding cycles we will have 1 or 2 Qual Iterations at the end of the cycle for a short Release Candidate period. External customer participation will be welcome as well to increase real-world testing.
On another topic, I have discovered 2 or 3 new blog sites that I am now following. These are great personal development blog sites that provide lots of positive thought-provoking inspiration to "be" better. We all want to "be" better, right? The better we "be" the better we "do". Take care of the "being" and the "doing" will follow.
First up is The Art of Manliness. This blog is an entertaining and informative resource with articles, blogs, and advice on how to be a better man. Even though it's primarily for men, there is a lot of good general advice for better "being". Man up!
Next is, Change Your Life. This is a more general recording of someone's personal journey toward self improvement. Again, lots of great thoughts and insights.
Finally, although I was not too impressed with the entire site, the Fifty Habits of Successful People was a good read. How many of these do you do? How many of them do you need to think about doing? Read them often.
I thought these sites were very good uses for blog sites. Spreading positive thinking is always good. We have enough negativity and fear already. We need more positivity, faith, courage and confidence.
Next Iteration will be a "Qualification Iteration". This means that there will be little or no new features added during the next 2 weeks while we submit release candidate builds to Customer Support to run real-world tests. The goal is to have a real RC1 by Wednesday. We may also do a late night Wednesday or Thursday night and provide dinner to the Support group and Development to encourage a focused testing window of 2-3 hours so we can try to flush out regression defects sooner rather than later.
Our plan is to do Qual Iterations at the end of each release. A typical release cycle will be some number of normal scrum cycles where we accept a set of stories and defects. After all the feature-adding cycles we will have 1 or 2 Qual Iterations at the end of the cycle for a short Release Candidate period. External customer participation will be welcome as well to increase real-world testing.
On another topic, I have discovered 2 or 3 new blog sites that I am now following. These are great personal development blog sites that provide lots of positive thought-provoking inspiration to "be" better. We all want to "be" better, right? The better we "be" the better we "do". Take care of the "being" and the "doing" will follow.
First up is The Art of Manliness. This blog is an entertaining and informative resource with articles, blogs, and advice on how to be a better man. Even though it's primarily for men, there is a lot of good general advice for better "being". Man up!
Next is, Change Your Life. This is a more general recording of someone's personal journey toward self improvement. Again, lots of great thoughts and insights.
Finally, although I was not too impressed with the entire site, the Fifty Habits of Successful People was a good read. How many of these do you do? How many of them do you need to think about doing? Read them often.
I thought these sites were very good uses for blog sites. Spreading positive thinking is always good. We have enough negativity and fear already. We need more positivity, faith, courage and confidence.
Tuesday, September 1, 2009
Agile Update
We completed our third Agile iteration last week. Each iteration we've done has been a bit different from the other. Our first goal is to simply learn to iterate. It sounds so simple, right? Just agree on a set of work to try to complete within a 2 week span and get on with it. For the most part, we have been successful at a basic level. Each iteration has started on a Monday and ended the following Friday. However, some observations are worth mentioning.
First, the background of the team was minimally controlled anarchy. It was an approach that has taken them very far. For most of the past history the team has been very small. We have grown the team by 2 or 3 new members over the last several months. The total is 9 developers, 2 test engineers and 1 technical writer. It is a good-size team for experimenting with Agile.
Before starting the first iteration we had trialed and adopted Rally as an Agile project management tool. Having this tool in place made it easier in many respects to be more successful that if we had not done that. For one thing, it allows us to be a "little" Agile in that we actually work more like an iterative development team with very short iterations than a true Scrum or XP approach. Adopting one or both of those approaches would have been a pretty radical culture shift for the team.
The first iteration felt a little frazzled. Some team members were stressed about getting everything done in 2 weeks, even though we had carefully scoped the work to fit. The additional urgency around actually committing to being done at the end of two weeks added energy to the team. Also, there were lots of questions about how to handle process-related things that came up. We learned a lot about Rally and how to use it to enable more efficient communication paths.
The second iteration felt a little more natural. We accepted a very high percentage of the work we had set out to accomplish. There were many less questions along the way and we adapted some of the practices we tried in the first iteration to be more natural in the second.
The third iteration was completely different. First, we started with much more committed work. We ended up only accepting about 45% of the work by the end of the iteration. That was good in that we learned that we can push work if it is not done and not feel too badly about it. Our average productivity over the 3 iterations was respectable. Pushing so much work into the next iteration renewed a commitment toward really being "done" with a story and not just chopping it up to make it fit within an iteration.
We had our first retrospective this past Monday at the beginning of the fourth iteration. The comments from the team were focused on how we get better at doing iterations. One common theme was the desire to do better at transtioning from one iteration to the next. Suggestions for a demo/planning day at the end of the iteration and more time discussing the stories at the start of an iteration were voiced. This will probably be the one thing we work on in this current iteration.
At this point our focus is on using iterations as a synchronization mechanism. We are not having daily standups (although we do send daily email status reports to the entire team with the same format as Agile standups). We do not do a good job of grooming the backlog and having stories fleshed out before we start the iteration. We are using an adjustment in "points estimation" that couples us a little too closely to concrete ideal time estimates. We also have to react to changes mid-iteration due to customer demands or whims within the company.
These are all things that need to be addressed over time if we are successful at getting real buy-in from other departments in the company.
First, the background of the team was minimally controlled anarchy. It was an approach that has taken them very far. For most of the past history the team has been very small. We have grown the team by 2 or 3 new members over the last several months. The total is 9 developers, 2 test engineers and 1 technical writer. It is a good-size team for experimenting with Agile.
Before starting the first iteration we had trialed and adopted Rally as an Agile project management tool. Having this tool in place made it easier in many respects to be more successful that if we had not done that. For one thing, it allows us to be a "little" Agile in that we actually work more like an iterative development team with very short iterations than a true Scrum or XP approach. Adopting one or both of those approaches would have been a pretty radical culture shift for the team.
The first iteration felt a little frazzled. Some team members were stressed about getting everything done in 2 weeks, even though we had carefully scoped the work to fit. The additional urgency around actually committing to being done at the end of two weeks added energy to the team. Also, there were lots of questions about how to handle process-related things that came up. We learned a lot about Rally and how to use it to enable more efficient communication paths.
The second iteration felt a little more natural. We accepted a very high percentage of the work we had set out to accomplish. There were many less questions along the way and we adapted some of the practices we tried in the first iteration to be more natural in the second.
The third iteration was completely different. First, we started with much more committed work. We ended up only accepting about 45% of the work by the end of the iteration. That was good in that we learned that we can push work if it is not done and not feel too badly about it. Our average productivity over the 3 iterations was respectable. Pushing so much work into the next iteration renewed a commitment toward really being "done" with a story and not just chopping it up to make it fit within an iteration.
We had our first retrospective this past Monday at the beginning of the fourth iteration. The comments from the team were focused on how we get better at doing iterations. One common theme was the desire to do better at transtioning from one iteration to the next. Suggestions for a demo/planning day at the end of the iteration and more time discussing the stories at the start of an iteration were voiced. This will probably be the one thing we work on in this current iteration.
At this point our focus is on using iterations as a synchronization mechanism. We are not having daily standups (although we do send daily email status reports to the entire team with the same format as Agile standups). We do not do a good job of grooming the backlog and having stories fleshed out before we start the iteration. We are using an adjustment in "points estimation" that couples us a little too closely to concrete ideal time estimates. We also have to react to changes mid-iteration due to customer demands or whims within the company.
These are all things that need to be addressed over time if we are successful at getting real buy-in from other departments in the company.
Friday, August 14, 2009
Holacracy
I was introduced to this concept a couple of weeks ago. It is a different way of viewing organizational structures. Traditionally we view things hierarchically with single lines of command and control and rigidity. Holacracy builds on Agile approaches to team process and scales the fundamental underlying concepts across the entire organization. The fundamental underpinnings are trust, communication, focus and urgency. Several of the higher conceptual layers are interesting.
At the highest level, holacracy views the organization as a collection of overlapping team circles of increasing scope. Each team circle is a complete cell with its own governance and processes. Each team circle is not self-directing, but takes flowdown from the next scoping level for direction. Each team circle elects a representative to link up to the next higher scope team circle. Each higher level team circle elects a representative to link down into the next lower scope team circle.
Another interesting concept is that of rhythm, the temporal heartbeat of an organization. Rhythm granularity is consistent for the overall organization as well as in the microcosm of each individual team. There are daily, weekly, monthly and larger scale rhythmic pulses for meeting frequency and structure. Daily standups are for quick fast-firing communication of what is to be accomplished that particular day. Weekly tactical meetings are for dealing with the necessary things to be done on a particular week.
Iterative tactical meetings organize execution for multiple week sprints that break projects down into manageable chunks. Monthly governance meetings are for discussing how the team/organization will work together and what changes need to be considered. Strategic meetings can occur quarterly or 1-2 times per year to look forward across a longer time horizon to adjust direction at a more macro level of control.
Holacracy is positioned as a new operating system for the organization. It embraces short bursts of activity toward a long term goal with frequent feedback loops and adaptive mechanisms for quick fine-grained steering. It draws from successful processes that have been pioneered at the team level and embraces, extends and scales these concepts up to the level of the organization.
At the highest level, holacracy views the organization as a collection of overlapping team circles of increasing scope. Each team circle is a complete cell with its own governance and processes. Each team circle is not self-directing, but takes flowdown from the next scoping level for direction. Each team circle elects a representative to link up to the next higher scope team circle. Each higher level team circle elects a representative to link down into the next lower scope team circle.
Another interesting concept is that of rhythm, the temporal heartbeat of an organization. Rhythm granularity is consistent for the overall organization as well as in the microcosm of each individual team. There are daily, weekly, monthly and larger scale rhythmic pulses for meeting frequency and structure. Daily standups are for quick fast-firing communication of what is to be accomplished that particular day. Weekly tactical meetings are for dealing with the necessary things to be done on a particular week.
Iterative tactical meetings organize execution for multiple week sprints that break projects down into manageable chunks. Monthly governance meetings are for discussing how the team/organization will work together and what changes need to be considered. Strategic meetings can occur quarterly or 1-2 times per year to look forward across a longer time horizon to adjust direction at a more macro level of control.
Holacracy is positioned as a new operating system for the organization. It embraces short bursts of activity toward a long term goal with frequent feedback loops and adaptive mechanisms for quick fine-grained steering. It draws from successful processes that have been pioneered at the team level and embraces, extends and scales these concepts up to the level of the organization.
Sunday, August 2, 2009
Retrospect: First Agile Iteration
Friday marked the end of the first iteration for the team. We finished respectfully, completing about 84 points of work with 82% story acceptance. These metrics will likely be adjusted Monday morning as we evaluate the status of the last few items to see what might actually be finished in the Monday morning build. The Monday build is the official Iteration 2009.2 build and should be archived for posterity.
Now that we have the first one out of the way, we have a start toward measurement. We can use the points completed in the iteration as a first estimate of how much work the team can finish in a 2 week period. We will get data for about 3 iterations and start averaging the number of points completed to get a baseline team velocity.
There were several learning moments in the first iteration. First, we did not do a great job of defining stories and acceptance criteria. While stories were created for bags of work, and some acceptance criteria was included, we did not create precise expectations around the format or the granularity of stories. Several team members are still struggling with the concept, since there is no such thing as a story template that is universally accepted. Stories are varied and customizable to the particular circumstances.
We also had questions around when the actual finish date for the iteration should be. Since the iteration ends at COB on Friday, many developers talked about needing to be done coding by COB Thursday of the last iteration week. This allows a day to fix any defects found by the test group on the last day of the iteration. Then, the official iteration build is the one created on the following Monday morning.
This week we do it all over again making incremental improvements on what we learned the last two weeks. We will have the team planning meeting tomorrow morning and cover the standard format for story description in Rally. This will include more precise information about what the story should do. We'll do a better job of having acceptance criteria meetings with sub-groups. Here we will refine the description of the story and add test cases as we discuss it. We will also do a better job of hourly estimates and individual capacity so that more of our tracking views will be accurate this time around.
Now that we have the first one out of the way, we have a start toward measurement. We can use the points completed in the iteration as a first estimate of how much work the team can finish in a 2 week period. We will get data for about 3 iterations and start averaging the number of points completed to get a baseline team velocity.
There were several learning moments in the first iteration. First, we did not do a great job of defining stories and acceptance criteria. While stories were created for bags of work, and some acceptance criteria was included, we did not create precise expectations around the format or the granularity of stories. Several team members are still struggling with the concept, since there is no such thing as a story template that is universally accepted. Stories are varied and customizable to the particular circumstances.
We also had questions around when the actual finish date for the iteration should be. Since the iteration ends at COB on Friday, many developers talked about needing to be done coding by COB Thursday of the last iteration week. This allows a day to fix any defects found by the test group on the last day of the iteration. Then, the official iteration build is the one created on the following Monday morning.
This week we do it all over again making incremental improvements on what we learned the last two weeks. We will have the team planning meeting tomorrow morning and cover the standard format for story description in Rally. This will include more precise information about what the story should do. We'll do a better job of having acceptance criteria meetings with sub-groups. Here we will refine the description of the story and add test cases as we discuss it. We will also do a better job of hourly estimates and individual capacity so that more of our tracking views will be accurate this time around.
Saturday, July 25, 2009
Scaling Agile Out
Even though we are just starting to incorporate some Agile techniques into our team's approach to building great products, I am keenly interested in the notion of scaling out across the company. I believe that Agile thinking is a head-on approach to embracing change and a natural way of increasing discipline at a number of levels. However, it requires flexibility and customization to the specific company culture and environment. Starting at the conceptual level and following principle is more important than mechanical adherence to recommended practices.
That said, some things are not negotiable. Two principles that fall into this category are rhythm and planning. These two principles are directly related and influence each other. Rhythm levels include daily, weekly, iteration(sprint), release, roadmap(see dissenting opinion) and strategic vision. Planning categories should include the same time spans. What are we doing today, this week, this iteration, this release, this year and the next 3-5 years? What are the mechanisms we use to synchronize and retrospect for each temporal category? Without this rhythm sequence supported by planning that overlays the same time spans, progress can wander aimlessly or at least in a less than optimum undisciplined path.
My plan is to focus on the bottom-most level and move up on two different planes. The first plane is local to the team. Implementing practices that support these levels of awareness within the team, then inspecting, adapting and refining will allow me to build a platform of experience that can be fanned out across the organization. My goal is to move the organization away from reactionary fire-fighting as much as possible and encourage a further refinement of sync and plan that energizes and increases urgency.
The second plane of bottom to top movement is within the temporal domains listed above. We already use daily status reports to communicate what was accomplished yesterday, what we expect to accomplish today, and what obstacles or concerns may exist. We sync up at least once a week to roll up the daily communication into a weekly assessment of progress. With our first sprint, we are beginning to add the iteration level. Releases, roadmap and strategic levels are less well defined at this point. My plan is to move bottom-up, mastering the iteration (sprint) first, then attacking rhythm and predictability at the other higher levels.
So far, the iteration rhythm seems to be the following:
That said, some things are not negotiable. Two principles that fall into this category are rhythm and planning. These two principles are directly related and influence each other. Rhythm levels include daily, weekly, iteration(sprint), release, roadmap(see dissenting opinion) and strategic vision. Planning categories should include the same time spans. What are we doing today, this week, this iteration, this release, this year and the next 3-5 years? What are the mechanisms we use to synchronize and retrospect for each temporal category? Without this rhythm sequence supported by planning that overlays the same time spans, progress can wander aimlessly or at least in a less than optimum undisciplined path.
My plan is to focus on the bottom-most level and move up on two different planes. The first plane is local to the team. Implementing practices that support these levels of awareness within the team, then inspecting, adapting and refining will allow me to build a platform of experience that can be fanned out across the organization. My goal is to move the organization away from reactionary fire-fighting as much as possible and encourage a further refinement of sync and plan that energizes and increases urgency.
The second plane of bottom to top movement is within the temporal domains listed above. We already use daily status reports to communicate what was accomplished yesterday, what we expect to accomplish today, and what obstacles or concerns may exist. We sync up at least once a week to roll up the daily communication into a weekly assessment of progress. With our first sprint, we are beginning to add the iteration level. Releases, roadmap and strategic levels are less well defined at this point. My plan is to move bottom-up, mastering the iteration (sprint) first, then attacking rhythm and predictability at the other higher levels.
So far, the iteration rhythm seems to be the following:
- Team scoping and commitment the morning of the first day of the iteration
- Team scope adjustment the morning of the second day of the iteration
- Daily ongoing individual status reports (email)
- End of week checkpoint to gauge progress and concerns with iteration progress
- Middle of the second week checkpoint to gauge confidence level of iteration progress
- Morning of the last day of the iteration - 15 minute standup to sync on what must get done that day to meet the iteration commitments
- End of day demo of accepted features for the iteration and pushing of incomplete work into the following iteration
Most of the meetings listed here are 15-30 minutes. The team scoping and demo meeting are more in the range of 45 minutes to 2 hours depending on the content. An alteration of this schedule might be to move to more traditional daily 15 minute "scrums" that might replace one or more of the other short meetings.
If we can master this rhythm, something like this might be scalable across the organization. Most of the time the organization tends to move at a more lumbering rhythm. Much has been written about the benefits of scaling Agile across the entire organization. Pulling decisions and actions forward and executing on a specific number of small tasks that are framed within larger goals is the motivation for adopting Agile principles across a larger scope of functional groups within the company.
Wednesday, July 22, 2009
Raising the Urgency Level
I just started using Agile methods in my job of running a software development team. We started our first sprint (iteration) Monday. We are not "both feet in" and only a few days have elapsed, but I already see a difference in the team's sense of urgency and energy level. We are using Rally, an Agile project management tool, to help us run the project. Our first iteration size is 2 weeks. The team was already a reasonably high-productivity team since, in general, everyone on the team is committed to getting things done the right way. What was missing was a little more structure and focus.
We met Monday morning to agree on the list of Stories (collections of tasks) for the iteration and make general estimates of the size of each. By the end of the day most team members had broken down the stories into multiple tasks with concrete estimates in hours for each one. Rally rolls up all hours estimated in tasks into the Story level and provides various views including full iteration and team member allocation. We met the next morning to make any adjustments, agree that the amount of work to accomplish in the 2 weeks seems to fit and clarify any other concepts that were fuzzy.
The team is new to Agile thinking for the most part. As manager of the team I mostly cover the role of ScrumMaster (to use a Scrum term). Scrum is a specific methodology of Agile. When I say that we are not "all in" I mean that we do not do everything recommended in the Agile literature. For example, we use email for daily status instead of daily face-to-face standups. This was a practice already in place when I arrived on the scene late last year. It seems to work well, and we have tweaked it a bit and critiqued it recently to try to make it better.
I subscribe to the method of gradually going Agile. I believe that if you have a team that is already flexible and productive, moving to Agile is a natural evolution. Not being burdened with a heavy Waterfall culture is a real benefit. A small-company environment where there is already fundamental trust and a little bit of development anarchy is much more of a blank slate in which to imprint a particular process, and Agile methods are a natural step.
There is a lot of information that preaches that Agile will fail unless undertaken under the watchful care of expert consultants and training programs. A lot of this information is produced by companies who make their living creating Agile development tools. I am not heeding that advice, and instead trusting that I know what I am doing from reading and leveraging over 25 years of experience developing and managing software teams in a variety of business circumstances and processes.
I may continue to post as the experience unfolds to record the pros, cons and results of this experiment.
We met Monday morning to agree on the list of Stories (collections of tasks) for the iteration and make general estimates of the size of each. By the end of the day most team members had broken down the stories into multiple tasks with concrete estimates in hours for each one. Rally rolls up all hours estimated in tasks into the Story level and provides various views including full iteration and team member allocation. We met the next morning to make any adjustments, agree that the amount of work to accomplish in the 2 weeks seems to fit and clarify any other concepts that were fuzzy.
The team is new to Agile thinking for the most part. As manager of the team I mostly cover the role of ScrumMaster (to use a Scrum term). Scrum is a specific methodology of Agile. When I say that we are not "all in" I mean that we do not do everything recommended in the Agile literature. For example, we use email for daily status instead of daily face-to-face standups. This was a practice already in place when I arrived on the scene late last year. It seems to work well, and we have tweaked it a bit and critiqued it recently to try to make it better.
I subscribe to the method of gradually going Agile. I believe that if you have a team that is already flexible and productive, moving to Agile is a natural evolution. Not being burdened with a heavy Waterfall culture is a real benefit. A small-company environment where there is already fundamental trust and a little bit of development anarchy is much more of a blank slate in which to imprint a particular process, and Agile methods are a natural step.
There is a lot of information that preaches that Agile will fail unless undertaken under the watchful care of expert consultants and training programs. A lot of this information is produced by companies who make their living creating Agile development tools. I am not heeding that advice, and instead trusting that I know what I am doing from reading and leveraging over 25 years of experience developing and managing software teams in a variety of business circumstances and processes.
I may continue to post as the experience unfolds to record the pros, cons and results of this experiment.
Subscribe to:
Posts (Atom)