Agile Chronicles

Agile or Iterative and Incremental

Mike Cottmeyer — 2008-10-02T06:53:37-04:00

Many companies want the benefits of agile but are not ready to make the organizational changes necessary to take full advantage of the methodology. Companies want to say they are agile… they want to derive the benefits of agile… but they are not fundamentally ready to do the heavy lifting required to really make it work. People want to hold onto predictive planning. They want to hold on to functional silos. They want to hold onto matrixed teams. People want to keep their specializations and spread their time over multiple concurrent projects.

What does a concept like velocity mean in such an environment? What about empowered teams? When I talk about iteration planning, daily meetings, and retrospectives; people can't comprehend how they will do this with every project they are working on. They fear they will spend all their time in meetings, and you know what… they are right. Agile assumes team. It assumes you are part of a cohesive whole that plans together, works together, and delivers together. Agile trades the big up front design, heavy documentation, and predictive planning for collocation, teamwork, and collaboration.

You can't collocate, work as a team, and collaborate when you spread across so many projects. You can't stop doing heavy project documentation if you aren't willing to replace it with high bandwidth communication between team members. To get that level of communication and collaboration, people need to be in the same room, they need to know each other, and they need to work together on a daily basis. People need to be part of a real team; not a collection of loosely coupled individuals.

The bottom line is this… you won’t get the speed and adaptability you are looking for unless you are willing to make the tough organizational changes that allow this to happen.

You can still get some mileage from delivering software in two or four week cycles, daily interactions between project members, and frequent project reviews. You can make use of loosely coupled requirements, prioritized backlogs, and rolling wave planning. There is value in understanding the definition of done and making sure that once you've delivered, you have really delivered. Managers can do product planning, release planning, and iteration planning without being particularly agile.

Even though you won't get the speed and adaptability of an agile team, you can still derive some benefits from iterative and incremental delivery. Just keep in mind that while agile prescribes iterative and incremental delivery, not all iterative and incremental delivery is agile. Agile adds all the aspects of team, collaboration, empowerment, inspection and adaptation. For a good article on the difference between incremental and iterative vs. agile, take a look at the following post I found on the AgileCollab blog:

http://www.agilecollab.com/iterative-and-incremental-is-not-equal-to-agile-key-aspects-of-agile

For a siloed waterfall team, this might be a good first step. It would definitely move the needle toward becoming agile.

What get's confusing is when we equate iterative and incremental with agile. Agile is incremental and iterative but it is also a value system… a way of structuring teams… a way of treating individuals. Agile is an approach to engineering products, a technique for managing projects, and philosophy for leading organizations.

It is valuable for leaders to know how to define what their teams are doing. It is valuable for teams to understand where they are in comparison to where they want to be. We can take baby steps towards greater organizational and project agility by implementing some of the practices. If we declare victory before we've done the hard work, we risk never meeting our goals and diluting what it means to be an agile organization.

We should acknowledge where we are, understand where we want to be, and ask ourselves if we are really willing to make the changes required to get there.

Image Source:
http://www.dorlingkindersley-uk.co.uk/static/clipart/uk/dk/rock/image_rock004.jpg

Empowering The Agile Team - Effective Managers

Lee Henson — 2008-09-30T12:17:46-04:00

Are you looking at me? This is where the real finger pointing begins. The fact is we need to assess the level of management oversight vs. the level of helpful management. This follows the Servant-Leader Principle. It is far easier for managers in these roles to stick to removing impediments and steering clear of the everyday nature of the work the team does.

Likewise, a good Product Owner / Manager can learn to stay focused on the customers needs and the direction the product takes to get there. The Project Manager should be focused on the success of the team and should really work to gain the team’s trust. This role should serve more as a consultant and mentor. The greatest fall any manager level position could take is to dive too deeply into roles outside of their own.

The fact is effective managers manage from the outside in. Worry about the bare minimum that you need to in order to insure the project’s success. Focus on removing impediments and providing the team the tools they need to be successful. In return you will receive the greatest level of visibility into the project.

The signs of an effective manager are a little more tough to outline on an Agile team. Not because they are doing less demanding work, but they are doing less work and more inspection and adaptation. Instead of steering a team to turn right, turn left, move slower, move faster, etc. the manager is spending more time removing the roadblocks and being a true team player. This does not mean they are spending great amounts of time analyzing things at the same level as the team. It does mean that they are taking the time to understand exactly what needs to be done and using that as a building block for team success.

1)Ability to Manage and Deal With Risk - Every decision an Agile team makes involves some level of assumed risk. It becomes the managers responsibility to assess the dangers ahead and steer the team on the most safe route. It is also the responsibility of the manager to highlight what facets of any given project are at risk.

2)Results Oriented - The Agile Manager worries a lot less about how many hours you have put in this week and worries a lot more about what you have produced as a result of the effort expended. This is not to say that we can completely do away with time as a fixture, there is always a cost to each output. This in essence says that our focus will be more directed to the output than the throughput.

3)High Energy – Nothing is worse than the ‘donut supervisor’. If the manager in question is never around (especially from a product perspective), that is an indication that you need to get someone involved that is a bit more excited about the teams’ accomplishments. A GREAT manager is engaged.

4)Team Player – The Manager of an Agile team should truly feel like they are a part of the team! Although they may not be allowed to constantly change requirements or verbalize why something is critical to be squeezed in, they are still a core part of the success of the team. In many cases they represent the team to the customer and or the customer to the team.

5)Multitasking Ability- The Agile Manager MUST be able to multi-task and be aware of the status, forecasted release, and daily progress of each project / product they are managing. This does require complete visibility into the project allowing the manager a chance to view information from a comfortable distance.

6)Improvement Oriented- Every Agile team thrives on the inspect and adapt model. This means they expect you to be at their demo. They expect clear and consistent feedback. This means they expect the correct resources to get the job done.

7)Listen First Speak Second- Silence is GOLDEN! Listening often clarifies what someone is really trying to say without you ever having to say a word. A great manager is always a great listener first. Once they have a clear understanding, then it is their time to speak and propose best practices.

Empowering The Agile Team - Product & Project Managers

Lee Henson — 2008-09-23T12:44:07-04:00

The Second round of finger pointing award goes to the Product Owner and Project Manager.

Did the Product Owner do his or her job of breaking down the Product Requirements Document?

Were all of the stories in the backlog clearly defined?

Did the Product Owner share in the Strategy set forth from the vision?

Was the Product Owner a true representative of the customer?

Was the Product Owner available to the team?

Was the Project Manager able to remove impediments in a timely way?

Did the Project Manager work with the team to help them plan for what their capacity would hold?

Did the PMO Organization pay enough attention to this high profile project?

Could anyone have assisted the team in their quest to do better?

The team often feels like one or many of the above questions went unanswered leading to the demise of the product or project. The fact is, the team needs to see that although these individuals could have contributed to the team’s inability to perform, neither of these individuals should be held individually accountable for their actions.

It is rare to see a manager in any role not have a desire to see the team succeed. More often than not, the team fails to see the effort put forth by these managers or they fail to consult them as a resource in the building process.

The manager role should be the resource you can rely on to get things done in a professional and timely fashion. It is the team's responsibility to ask as many questions as needed in the planning stages to avoid having to review the list of questions above later.

Next week we will continue searching for clues by looking at the roles of team leads and other subject matter experts. We will also look at the inpact of third party organizations that could affect the Core Agile Team.

Agile and UI Design

Mike Cottmeyer — 2008-09-16T10:22:19-04:00

A few days ago, one of my Twitter buddies asked me to explain how the UI designers fit in on an agile team. I have some experience working with dedicated design teams and user experience folks so I thought I'd take a stab at his question and share my perspective. Once I finished my note it seemed like it might make a good blog post. I'd be interested to hear what you guys think about my answer.

Here goes...

Just to set a little context... my friend asked me to explain the role of the UI designer on an agile team. He explained that they were creating user stories but were not sure how to incorporate the UI designers into the process.

The unfortunate thing about explaining agile is that there is no one right way of doing things. There are principles that I like to see teams apply. Agile is all about creating situationally specific strategies. You just take the principles of agile and apply them the best you can given your constraints.

That said.. my friend seemed to be on the right track. They were creating stories with using a typical agile patterns... "As a user, I want to be able to create a new account, so that I can do X". The principle that I encouraged him to apply is that the story is small enough to be done in a single sprint, all disciplines are involved in implementing the feature (including the UI guys) and at the end of the sprint, it is potentially shippable... in other words, done.

What would that ideal look like in real life? During the sprint planning meeting, the team would collaborate around a whiteboard on what it means to be able to create a new account. The developer might talk about what methods might need to be created. The QA engineer would discuss how it would be tested. The UI designer would be involved helping the team understand what the screen would look like. The product owner would weigh in on the business value and keep the implementation discussions in check.

At the end of the discussion everyone is on the same page about how the feature will be built. Since everyone is on the same page, the UI person can go off and start iteratively working on a mockup (if necessary), the developer goes off and does code, maybe the QA person goes off and starts test planning. If the team is pushing new code up every day, continuous integration in other words, everyone gets to see the evolving product and respond to it.

Just like the code evolves, the doc evolves, the plan evolves, the product evolves.

The typical response from dedicated designers and QA people is that they want to be able to do the work once and for all. Operating in this way feels like waste. I encouraged my friend to keep in mind agile principles like barely sufficient documentation, simplicity of design, deferring decisions to the last responsible moment, and constant refactoring... The key is to keep the focus on working product and off comprehensive documentation.

Just like the dev team will refactor often, the supporting team members may have to refactor as well.

But what if everyone is not in the same room, on the same team, maybe not even in the same company (external customer)? You apply the same principles and adapt them to your environment. I have seen teams do just enough UI design in the previous sprint to keep the dev team moving in the subsequent sprint.... This makes things more complicated and creates more dependencies than an pure agile approach.

When teams take this approach, I liken it to the product owner grooming the backlog and specifying requirements in advance. The UI mockup becomes like a requirement to the dev team.

As a team you just have to decide how much time and energy you want to invest in up front design. You can do agile practices with an up front design, it just causes you to do even more rework if you want to change anything. It really depends on the uncertainty of your market. If things are prone to change, invest less up front. If things are stable, you can invest more.

Photo credit: jaysmith.us/wp-content/uploads/2008/06/agile.jpg

APLN Atlanta Leadership Summit - Early Bird Rate Extended to September 24th

Mike Cottmeyer — 2008-09-15T16:41:47-04:00

We are interested in helping as many people as possible attend the APLN Leadership Summit next week. Yes... next week... it is nearly here.

To that end, we are extending the $399 early bird price up to the day before the summit. This is going to be an excellent event and well worth the price of admission.

Michele Sliger from Sliger Consulting and former Rally consultant is speaking on bridging the PMI world to the agile world.

Roland Cuellar is speaking on agile portfolio management and agile metrics

David Hussman from DevJam is speaking on buidling test driven organizations and agile architecture

Peter Hodgkins from Enthiosys is discussing agile product roadmaps and their relationship to quality

Mitch Lacey is going to discuss roles on agile projects and the challenges when we wear multiple hats.

In addition to the outstanding lineup of speakers, we have 5 leaders from Atlanta and the Southeast that have led, or are leading, agile transitions. We are fortunate to have the following leaders come to help:

Paul King - VP Products and Engineering, Agentek, Inc. - Alpharetta, GA
Rick McMichael - VP Product Development, CheckFree - Norcross, GA
Bob Myer - Pillar Technologies, President/COO - Columbus, OH
Steve Cover - Sage Software, VP R&D - Lawrenceville, GA
Bud Phillips - Valtech (former VP at CapitalOne) - Richmond, VA

Come talk to these guys and see how they did it.

Finally we have three awesome keynote presentations.

Robert Holler from VersionOne will be speaking on the need for Agile.

Bud Phillips from Valtech will be exploring the creation of a
development value chain

One of my personal favorites, Christopher Avery will be talking about leading responsible agile transitions.

Needless to say, we are going to feed you some great food the two days you are with us and we'll have an open bar Thursday night... just in case you needed one more selling point to throw you over the edge!

Time is running out. Register today to secure your spot!

For more information visit: http://summit.aplnatlanta.org

To register: http://www.regonline.com/Checkin.asp?EventId=628805

Empowering The Agile Team - Looking for Clues...

Lee Henson — 2008-09-15T15:51:08-04:00

A great place to begin the search for clues is to begin analyzing the levels of Agile planning and assessing if each party participated at the correct level.

Often times the primary group looking to hold someone responsible for project failure is the Executive Team. In other words, be prepared to give a complete report on why the team failed to deliver exactly what we wanted on time.

Have you ever considered doing a Demo and only showcasing the work that has been completed? What reaction might you expect from the Executive Team if they are present? What could you have done differently to alleviate the pain in the future? The answers are our next set of What if's?

What if we had the ability to promise both on-time delivery and precision metrics? What if we could help the Executive team better understand their role in the agile process? What if we had the ability and power to help frame the Executive Vision?

When I say Sail Well, what specifics might come to mind? Some may consider this a token of great advice, but the question remains is this really great counsel for an agile team? What exactly does sail well mean? Does it provide a concrete direction? One could argue that with direction already solidified, this advice could be the first indication of an executive maintaining control of the vision while allowing the team to chart it's own course.

We all know there is more than one way to reach the final destination. This may be why I select to use the word strategy in lieu of vision. Vision indicates a dream or long term goal that has suddenly become within reach. Strategy includes vision and careful planning with the rest of the crew to make certain the ship remains on target. Charting the most desirable and or efficient course becomes the next step in the process.

Consider the difference between basic vision and having a strategy in place. Take the time to find the most strategic solution. Now is also a great time to realize that the Executive team is NOT at fault. Should the strategy not be clearly outlined, someone should be speaking up! It is the Team's responsibility to provide the needed visibility to the executive at every level in order to assist them in maintaining the project at their respective level.

Step One to being an Empowered Team is "Learn to Sail Well", even if there is a storm out there!

Next week we will study deeper and look at the role of the Product & Project Manager.

Using the Open Platform to create Custom Reports or Story Cards

Jerry OdenWelder — 2008-09-07T21:24:55-04:00

Picking up where I left off, suppose I needed to retrieve stories for a specific project or a specific iteration in our system. In order to filter a Story query by project you need to use the Scope attribute in the where clause. By default, this parameter expects the object identifier for the desired project; however we can use the Scope.Name attribute and specify projects by name. For example, to select all stories for a project called "Release 1.0" we can issue the following query:

http://localhost/VersionOne/rest-1.v1/data/Story?sel=Name,Number&where=Scope.Name="Release 1.0"

When you want to filter by iteration, you need to use the Timebox attribute (or Timebox.Name) in the where clause. With the following query the system will return all stories in an iteration called "Month C 1st Half":

http://localhost/VersionOne/rest-1.v1/data/Story?sel=Name,Number&where=Timebox.Name="Month C 1st Half"

You can combine these parameters using the 'AND' operator. In the VersionOne API the 'AND' operator is a semicolon (;).

http://localhost/VersionOne/rest-1.v1/data/Story?sel=Name,Number&where=Scope.Name="Release 1.0";Timebox.Name="Month C 1st Half"

The API also supports an ‘OR’ operator, the pipe character (|), although it’s not very valuable in this situation.

If you are trying the examples as we go you’ve noticed that all results are retuned in XML. This makes the API very powerful, but the results hard to read. The VersionOne API provides support for XSLT transforms. This is accomplished by using the ‘xsl’ parameter in the URL to specifying an XSLT transform file. When this parameter is detected, the API results are passed through an XSLT processor before being rendered. Using this technique anyone can create custom reports using VersionOne data. As an example we can take the previous query, modify it slightly, and produce Story Cards

http://localhost/VersionOne/rest-1.v1/data/Story?sel=Name,Number,Owners,Estimate,Description&where=Scope.Name="Release 1.0";Timebox.Name="Month C 1st Half"&xsl=Custom/StoryCards.xsl

A few things to note about this query:
1. I added Owners, Estimate, and Description attributes to the selection parameter
2. I added the xsl parameter to the end of the URL and supplying an XSLT transform file called StoryCards.xsl which is located in the ‘Custom’ subdirectory under my VersionOne installation directory.

What does StoryCards.xsl look like? Earlier this year Maggie posted a discussion to our developers community group that included this information. Click here to read her message and download the file. (Thanks Maggie).

Next up, we’ll talk about sorting query results and the aggregate functions available through the API.

Empowering The Agile Team - Does This Apply To Me?

Lee Henson — 2008-09-04T15:10:27-04:00

Many times we question the what if’s and how they apply to what I do. One of the very earliest projects I had the privilege of working on involved having an active Marine General as the end customer. For those of you without military experience, we are talking about the most impressive form of command and control management ever known to exist. The youngest Marines are educated by their senior officers based on years of experience backing every decision made for them.

One might go as far as to say that by letting go of the reigns, any complex project would enter a vortex of hopelessness and spin out of control ending in a fiery crash. I am here to state to you all this is simply not the case. In fact, it is almost entirely the opposite approach that works best. Once a team understands what they are being asked to complete and why, they are generally more successful than teams that rely on the command and control structure. My what if conversation went something like this:

What if we didn’t jump into this Agile thing feet first?

What if I just kept a running list (backlog), of the things I felt should be worked on first?

What if we met daily for our recap as opposed to meeting once a week for several hours?

What if I could provide you with samples of completed work every 2-4 weeks and let you inspect our progress?

What if I could assure you that by placing confidence in the members of the team that the project stands a higher chance of being completed on time and within scope?

Who's fault is it?

Let the finger pointing begin! This is the place where the rubber hits the road. It is especially easy for people to quickly assess the situation and identify anyone else who was the cause of the debacle. This is the greatest point of contention amongst teams. This is also the greatest opportunity for the team to retrospect and adjust in order to prevent this from happening in the future.

The key here is to stop pointing fingers and start searching for clues…

Next week we will look into the executive role and see if they are the culprit.

Empowering The Agile Team - The What If's?

Lee Henson — 2008-08-28T00:11:33-04:00

In this series we will learn more about empowering the agile team and the action each role can take to help guide the team to success. The What If’s? are quite an interesting bunch. I remember the day when my children first stated asking this very question. It all starts with a seemingly innocent request:

Can I ride my bike to the park? …No, not now

What if I invite a friend to come along? No = What she really hears = You do not trust my friends?

What if I ride slow? No = What she really hears = You feel I am not safety conscious?

What if I walk instead of ride? No = What she really hears = You do not even trust me to walk across the street?

What if I just don’t go? What she really hears = You do NOT trust me at all?

Agile teams feel very much the same way when we do certain things in the workplace.

Why did this project fail? Why did we deliver late? Why did we exceed our budget?

The plan to execute did not match the strategic vision of what the customer wanted = The executive vision was not accurate and / or not communicated well.

The management team failed to provide me with the tools / resources I needed to do the job to the best of my ability. = It’s a managers fault.

The requirements were not clearly defined or, we did not have a clear interpretation of what was to be done. = It’s the Product Owner

We had too many outside interferences and were constantly putting out fires. = It is the Project Manager or ScrumMaster

We simply failed to get it done. We the team take full responsibility.

In other words, the first key to success as an agile team is to say what they will do and do what they say. This simple natured gesture may seem light on the surface, but the fact is many agile teams do not take their commitment as a team as serious as they should. Next week we will dig deeper and attempt to identify the root of all evil that blows an Agile project apart.

Atlanta APLN Leadership Summit: Early Bird Expires on August 31st

Mike Cottmeyer — 2008-08-25T09:17:44-04:00

Early bird rates expire on August 31st. After the 31st, the price of the conference goes from $399 to $599. The conference is an exceptional value at $399 so make sure to register this week to take advantage of the early bird pricing!

"Leading the Agile Transition"

September 25th and 26th
Marriott Atlanta Perimeter Center

http://summit.aplnatlanta.org

We are proud to announce that the next APLN Leadership Summit is coming to Atlanta!

For the past few years, local APLN chapters have organized and hosted regional Leadership Summits. These events have been very well received and attract fantastic speakers and exceptional local thought leaders.

This is your chance to attend an Agile conference specifically designed to address the needs of the Agile community in Atlanta and the Southeast. Our speakers will discuss topics ranging from Product and Portfolio management to Agile Architecture and Metrics. Each speaker will present two talks, one geared toward the practitioner that is looking for tools and techniques they can use on a daily basis, the other toward leaders considering, or leading, a switch to Agile.

The summit is geared toward new and seasoned Agile leaders at all levels: organizational leaders, product leaders, development leaders, and project leaders. This is your chance to spend a whole day with some of the leading experts in the area of Agile Leadership, to network with with other agile leaders, and to share your experiences and concerns with those who are in the same situation as yourself.

The Dallas and Seattle Summits were a huge success! Next up is Atlanta!

The APLN Leadership Summit format includes:

Networking opportunities throughout the day
Speakers addressing how to lead their organizations to become agile.
"Think Tank" sessions on Agile Leadership with topics addressing advanced leadership tools, experiences, lessons learned, and issues yet to be resolved.
Networking social at the end of the first day to review think tank solutions and suggestions.

The APLN Atlanta planning committee has lined up an all star group of speakers and local Agile leaders. The conference is limited to 120 participants so you need to act now. If you are in the area, or able to make a the trip, the Atlanta Summit will be well worth attending.

For more information (including speaker bios and abstracts) and information on how to register, please visit the APLN Summit home page: http://summit.aplnatlanta.org