In the world of IT, as systems become more powerful and complex, managing these complex systems becomes easier and easier. A big part of what I have dubbed the IT revolution comes from a new group of revolutionaries pushing forward the message that serious does not need to be complex. In the world of agile development, we have been advised that agile does not mean fragile. Today I am going to zoom in to a little old thing called Scrum.

When Scrum was invented and first implemented, it was meant to be a simple framework with few roles, meetings, and artifacts. I now feel no choice but to ask, what in the world happened to the simplicity? As it has evolved, Scrum and agile project management in general have become polluted. I have even heard many agile scrum coaches proclaim that a ‘vanilla Scrum’ implementation will only work in small organizations with simple projects. Although this could be no further from the truth, I still feel the pain from teams who are suffering from being bitten on their Scrum-butts!

All too often, at the direction of someone in an agile management position, we abandon the simple things we know to be true. Whether it is done in an effort to find the holy grail of increased efficiency, or to make the adoption an easier to swallow pill, does that make it all right? Does simple with few rules, roles, and artifacts necessarily mean easy? Where do we draw the line? 

In this article, I intend to present why teams choose to struggle with something so simple. Let’s start by taking a walk down Scrum Lane and discussing some of the pieces that people struggle with most.

Roles
The first of three concepts we will discuss today is roles. I cannot help but notice that one of the largest questions organizations face as they transition to agile is "where does my role fit into the mix?" People are constantly trying to squeeze what they do into the agile mold, when in fact there are truly only three positions, regardless of agile methodology: Customer, Implementor, and Facilitator. In Scrum, the three roles are Product Owner, Scrum Master, and Team Member. Each role has been called a number of different names, but the simple truth is no matter what HR calls you or what is on your business card, you should fall into one of these three roles. If you do not, it may be time for you to do a serious introspective and identify how you can modify your role to fit better into one of the three identified.

Meetings
The second concept up for discussion is the correct Scrum meetings. Scrum was founded on the premise of three meetings. The first is the Daily Standup (or Daily Scrum). The daily meeting is a chance for the team to report their progress to each other! This is the perfect time for the team to use subtle pressure to ensure accountability for each individual. The meeting has only three questions for each individual to answer:

1)      What have you done since we last met?
2)      What are you planning to do until we meet again?
3)      Is there anything preventing you from completing the items you committed to? 

The meeting is capped at fifteen minutes in length. No problem-solving happens here. The team simply identifies issues and takes them offline to resolve. Attaining the right level of detail is the key to making this meeting successful. This meeting should happen in the same location at the same time, every day without exception.

The second meeting is Sprint Planning. The most common misconception is that no initial preparation takes place prior to this meeting, which is simply not true. Key considerations must be met to achieve success. The product backlog must be properly groomed and backlog items must be ready to be placed into a Sprint. An architectural runway must also be in place for the team to be able to successfully plan for the work. Many people forget these critical steps, and when this falls squarely on the team, the team fails. Effective Sprint planning largely contributes to a team’s success in adopting or implementing Scrum.

The team should meet at the beginning of the Sprint to review the work for the upcoming sprint and break the work down into small tasks and tests. This is a learned art and you should never expect a team to catch everything on the first pass. This meeting should be brief and time-boxed equivalent to one hour per week of your team’s sprint length. Four week sprint = four hour meeting. Proper execution in the Sprint Planning meeting is critical to the team’s success.

The third Scrum meeting is Sprint Review, which includes the demo and retrospective. Of all the Scrum meetings, this one can prove to be the most beneficial to the success of the team. The entire concept of inspection and adaptation rides on the premise that the key stakeholders will have a chance to review what the team has created and to provide instrumental feedback. This feedback is what helps the team stay focused on exceeding the stakeholder’s expectations and allows all key parties to be on the same page. The retrospective is the only opportunity that the team has to inspect and adapt the process. Although at times the meeting may turn toward evaluation of individuals on the team, it is critical to maintain focus on the process and look for ways to prepare an agenda that allows the team to stay focused on delivering meaningful results in the retrospective. The team will be grateful that you helped them stay on track.

Artifacts
The third and final concept to keep Scrum simple is focusing only on the three artifacts. The three Scrum artifacts are as follows:

1) Product Backlog – This should be a well-managed list of work to do in upcoming sprints. The work should be broken down in a manner that makes it easily consumable within a single sprint.
2) Sprint Backlog – This backlog should contain all of the small tasks & tests needed to complete a subset of work from the product backlog. This is the actual work that the team commits to deliver.
3) Burndown Chart – This visual indicator is a constant reminder of the work remaining to be completed as part of the sprint commitment.

I think too often we try to take this very basic framework and overcomplicate it to fit our organizational culture. If we get back to basics, and focus on keeping it simple, we will all re-discover that Scrum is a true flavor of agile project management and it really does work!

One question that I run across quite often is "What will agile development do for my organization?" What many people mistakenly do is equate agile project management with doing more work, with less documentation and fewer people. Although the premise is to get more done in a more favorable way, I have never met a team that could successfully implement agile principles without having to slow down first.

In fact, I would challenge that initially agile development causes teams to move slower! I know what your next question is: "Why bother?" Well, please allow me to clarify. Agile project management is your friend! Many managers do not take the time to understand what agile of any flavor will do and are completely caught off guard when they discover that things do not always fall out exactly like they had envisioned. 

After enduring endless nagging by my peers, I decided that a guide was needed for managers to set true expectations with regard to an agile development project roll out. When I consulted with some of the organizations I have worked pretty extensively with, they all replied that they would be delighted to give me input, but were disappointed that it would take me this long to put a simple list like this together. For all of you who wish you had this already, I am sorry in advance. Now is the time to get busy and take action! 

This two-part series will engage agile managers at any level and help them best understand the fundamentals and embrace what they need to know about agile. The long-preserved secret is that agile project managers really only need to know three things to be successful.

1. Become a servant leader. Although it may take some time to redirect your energy toward removing obstacles, the new focus will allow you to concentrate more on the larger picture and less on the day-to-day needs of the team that works for you. Less command & control and more accountability will make you a sure winner.
    
2. Allow agile to identify areas where improvement is needed. I recently engaged an organization and met a non-believer. When I asked him about his experience with agile, I nearly had a heart attack when he claimed that it simply does not work. "All agile did was identify all of the things we were doing wrong," he said. I just smiled and nodded. Those are the things that you were meant to be doing better. Take advantage of this golden opportunity and allow agile to help you get better!
    
3. Take the time to understand the fundamentals of the framework, methodology, and terminology! How much more will the team respect you for taking the time to invest in their success by learning more about what you are asking them to do? We all know that things will need to storm a little before becoming a high performing team.

The first step will be the easiest one. It is all a matter of breaking down where and how accountability may rest. Most managers fail to realize that there are qualified people who work for them that can take on most of what you throw at them. I often find myself in management sessions telling them to try and delegate their way out of a job. I assure them that by doing so, they will find new ways to engage and work with the organization and find new ways to help them be successful.

It is essential to recognize that a large number of the problems teams face can and should be handled by the team themselves. If the team ever encounters a problem that is out of their league, they will always have someone to turn to in the form of a project manager, ScrumMaster, or product owner who can assist them in resolving most common issues. This is the second line of defense.

In rare cases where this second group cannot bring resolution to an issue, the issue is sometimes brought to the attention of management. I guess this begs the question, "How do I keep busy now?" Well, for starters, this allows you to better focus on delivery and execution of the vision. Many agile organizations get lost in the vision and lose focus on the strategy needed to execute the vision. If the team has a clear path and direction from you, they will be successful.

Once you realize that you can relax, the final step is to help the team understand commitment and responsibility. When I am working in the role of management, many people comment that I allow my teams an excessive amount of responsibility. I let the teams self-regulate for the most part, and hold each other to the highest standards. As a result, I am able to set my expectations very high. There is no confusion surrounding my expectations: I fully expect that you will do all that you have promised. This type of relationship is healthy and the teams enjoy both the freedom and the level of accountability I hold them to.

The next step is to allow agile to identify key areas for improvement. Do not fear what the agile process identifies! In fact, I hope that you will embrace and address all that comes to the surface.

One of the keys to agile success is transparency. The right hand needs to know and understand what the left hand is trying to do. The teams will have the greatest chance of success when common obstacles can be identified and removed. Teams discover that the business transforms into a place where they actually enjoy coming in to work. Without transparency, this could not be possible.

Embracing transparency and what it exposes is not intended to be an easy undertaking. Expect the storm and celebrate the success once the storm dies down and the team embraces accountability. Managers become part of a brain trust that will rely on results of the delivery team in order to make sound financial and business decisions. The key here is to teach the teams that with great power comes great responsibility. They will continue to be cast in a positive light for as long as they continue to deliver.

Finally, in order to be successful, you need to show the team that you have a vested interest in their success. This is your chance to do the research needed and show the team that you do understand what they are doing and support their effort. In early 2010 I hope to publish a glossary for managers that will assist them in finding the information they need to help their teams taste success.

Until then, I have left you with enough to work on. Enjoy the post and I will continue soon.

At this time of year, each of us have made New Year's Resolutions. Some of us want to lose weight, or eat less sweets. Some want to exercise more often, or just get in better shape. In the agile development community, I am asking you to consider a different type of resolution. It is all well and good for us to do any of the items listed above. They will each help us to become a better person. The question I have is, "What can you do to better implement agile processes within your organization?"

Over the next few weeks, I hope to address topics regarding agile adoption and what it should mean to you and your organization. Call me a personal trainer if you will, but I remember the difference between when I attempted to lose a few pounds on my own, and when I had the help of a personal trainer to assist me. With a lot of focus and a little boost from someone on the outside, I got to see amazing things happen.

I am hoping you will take advantage of my writing as we take an opportunity to study each role in the agile process in review, and attempt to identify ways that we can have a better or renewed impact on our projects. Let's take the time to inspect and adapt ourselves and make the new year one to remember. Although for many of you this may feel like a quick refresher course, I hope that you will patiently follow along and just try to identify one way in which you could ratchet it up a notch.

We will begin the series by addressing the needs of the business and focusing on why managers adopt agile frameworks for their organizations. Let's get started and I look forward to working out with you and performing our Agile Tone Up! May this New Year and decade bring you much health, wealth, and success!

We all know the benefits of agile when developing software, but are you using those same principles with your marketing efforts? Treat your marketing initiatives like any other agile project by breaking big ideas into small deliverables.

For example, launching a marketing microsite sure sounds like an epic undertaking but breaking into smaller pieces makes the project much easier to deliver. Start by building a simple webpage with links to existing content (blog posts, articles, whitepapers, presentations) and add new content to the site (podcasts, webinars, videos) with each iteration. Get feedback early and often so you know you’re creating what your audience wants. Once you have enough content, you can divide it into multiple pages and before you know it you’ll have a full blown microsite.

Agile project management has finally started to grow up and mature. On the heels of multiple training and coaching engagements, one thing I have learned is that agile has certainly made its way into enterprise level application development. Software development tools have evolved, and people have changed the end delivery method for getting things done. One constant that has held true throughout the test of time is the capability to work in an environment where everything is visible.

Many agile organizations struggle with the prospect that visibility and transparency may not help everyone see eye to eye. The fact is, even though agile, Scrum, XP and the like have all taken monumental steps toward enterprise level adoption, the key to organizational success remains establishing and maintaining a solid foundation. One core success factor remains the ability to retain transparency and keep focus on the ability to inspect and adapt. This is not intended to be confused with scope creep or gold plating.

In fact, one of the biggest hurdles I run into when agile starts to grow is the inability of the organization to learn from and accept the nature of what change has presented. Although from a business perspective we may all still see things a little bit differently, we need to learn how to keep our focus and learn from the error in our path. We need to take on the pressure of increased visibility and treat it as an opportunity for growth.

Whether our team is just passing through storming and beginning to norm, or just beginning to form and has not reached this monumental step, we need to teach people that it is better to see eye to eye, and that even though the road may not always be a primrose path, the path we take will continue to teach us to be the best we can be with regard to agile project management. Enterprise level agile adoption is not always an easy sell, but neither is any process that may require us to refocus and slow down a bit.

Let us each take a step back and a deep breath. Even though we may not be resolute in our belief that complete transparency will lead to enhanced process scenarios, we will quickly grow to understand that success relies on our ability to accept these core fundamentals.

My name is Aubrey Johnson (@aubreyjohnson) and I’m a designer here at VersionOne. In my first month-and-a-half incorporated into an Agile team I’ve learned a good bit about iterative processes, agile project management, and self-discipline. I’ve discovered that agile methods aren’t just for developers, and iterative work approaches can work (with some slight modifications) for pretty much anyone.

In my previous experience everything was waterfall driven. We’d toil and work on a project for months, tweak it, watch others get to market first, explore feature creep, and finally launch a product... often to revisit it shortly after with minor modifications.

VersionOne has changed the way I approach design, in a great way. Getting constant feedback for a project to ensure that it's aligned with the company goals and vision, turning over work in shorter time frames, and helping others in areas where I have a background have all made me feel like I’ve accomplished more in the past month and a half than in the previous year of work.

Seeing visual progress and finished work is so rewarding as a designer, I can’t help but wonder if other designers would like to the utilize this process of Agile project management in their own agencies and firms. I am looking forward to continuing to design iteratively, with feedback, and constantly seeing finished projects that I can add to my portfolio.

Feel free to drop some comments about how you think your work environment could benefit from having daily stand-up meetings, chartable progress, and breaking large projects into workable chunks. I’d love to see if Agile processes are working in other non-developer roles out there.

 

Twas the night before code drop and all through the land
Not a person was coding, not even one hand

The code was all tested and checked in with care
Even the documentation was completed and there

The PMO Director & VP of Dev were nestled all warm and snug in their beds
While visions of bonuses danced in their heads

Joe closed his laptop and Sue hit the sack
Knowing morning was near and they needed the nap

When from my pocket there arose such a clatter
I reached for my iPhone to see what was the matter

To the office I flew like a Senior VP
Tore open my briefcase and fired up the PC

When what in my unsettled eyes might appear
But an incomplete test case as I trembled in fear

I regained my senses and checked out the code
Reviewed the regression and distributed the load

It passed all the tests now, my mind was at ease
Knowing that many would certainly be pleased

That I put forth such effort on a cold chilly night
To re-sync our code and ensure all was right

Soon morning approached and I knew not to worry
As none of the testing was crammed in a hurry

It makes my heart filled with holiday cheer
To know Agile methods make everything clear

As the holidays are with us and our hearts fill with joy
Help us all to remember the framework we enjoy

On XP, on Scrum, On Kanban & Lean,
On DSDM, On AgileUP, On Crystal Extreme

To the ends of the project, no greater joy shall we call
Than celebrate, celebrate, celebrate all

As we conclude the current project and realign our sites
Happy Holidays to all and succeed with Agile Might!

Fishbowl discussion panels are a great alternative to traditional conference speaker panels. The key word is discussion - a discussion that happens strictly between the fishbowl panelists. There are six chairs set up in a slight arc, and one chair is always empty, so there are a total of five panelists at any given time. Discussion only occurs amongst the panelists. If there is an audience member that would like to contribute to the conversation, they need only get up and sit down in the empty chair. At that point somebody already on the panel must get up and sit down in the audience.

There are a two important points to discuss with both the audience and the panelists:

• If you sit down to be part of the panel you cannot simply state your point and return to your seat in the audience. You must wait until someone takes the empty seat – and be quick enough if there is somebody else looking to get into the audience!
   
• This is meant to be a discussion and long diatribes are discouraged. Don’t be afraid to light-heartedly scold someone for going on too long.

Seeding the panel questions
When running a fishbowl at the end of a day of presentations, it can help to make sure there are flip charts or a white board in each presentation room.  Attendees must be encouraged throughout the day to add their questions. These questions are collected and projected to the audience and panelists (if the projection can also be seen by the panelists it can help keep them on point). When a question comes up that is not clear, you can ask the person who wrote it to give context.  The key here is to make sure they are brief.

If collecting the questions beforehand is not possible, you can always take questions from the floor. The downside is that when people write down their questions it forces them to be concise.  Questions from the floor can be much more open-ended because people tend to describe the question instead of asking it.
 

Keeping the questions moving
The discussion for each question is initially limited to a maximum of five minutes. After five minutes the audience votes whether there are five more minutes of discussion, or whether to move on.  This keeps the control of discussion in the hands of the audience as a group, and doesn’t allow one topic or person to dominate. We hand out auction paddles for voting that are red on one side (move on) and green on the other (five more minutes).   Prior to the auction paddles we used open palm (move on) and closed fist (five more minutes). This wasn’t as easy to judge sometimes - the big swaths of color really help.
 
A very special thanks goes to David Hussman for originally suggesting this technique for our first AgilePalooza in Minneapolis, and also for the idea of having a red card/green card for voting.

there seems to be an ebb and flow for this sort of thing. recently i read a discussion on the idea of a technical business analyst and how the business analyst role is evolving in project management. there was an argument that business analysts [ba's] are like wait staff. wait staff ask the customer what they would like and submit an order. they are never asked to go into the kitchen and cook. so why should a business analyst get into the pit and code?

if we continue with the metaphor above, customers are constrained to those items on the menu as well as the types of substitutions they may request of the kitchen staff. a good, or well trained, wait person will know these nuances very well and coach the customer to meet these constraints. if the waiter is unsure, they might ask if a request is appropriate before committing to the customer. otherwise, they will have to tell the customer that they have made a mistake committing to their request, or that there is a slight up-charge for doing so, or it may take a little longer to prepare. the story could continue, but i think this is a probable scenario.

my first question is, is this an appropriate comparison? does it hold water? in general i say no, but if we expect as much from an agile business analyst then it could be. based on my experience, there is usually a highly adversarial and dogmatic approach in favor of the customer by ba's in an agile software development environment. this may not be acceptable or typical, so i admit to a potential bias.

ultimately and imho, absent specialized skill sets (which is the direction of the industry in general), distribution of effort is delegated to the other people actually doing the work. for instance: in an agile development organization where ba's are limited, the responsibility is delegated to other members of the project delivery team, be it the pm, dev, qa members, etc. is it as high-quality as what a ba might produce? maybe, maybe not. but we know that the division of work is distributed, as developers are asked to have business acumen, qa is asked to do some development, etc. expertise is expensive, and very few are worth it despite the skill being sought.

so another question would be, what makes the ba a specialization that should be maintained in the field?

ba's work for both sides in an agile context. the walls are crumbling between business and technology. 'us and them' is becoming 'we'. i don't think it helps to compare ba's to wait staff. let's change context for a moment. in most automotive service departments you're not likely to find specialized technicians (tranny, engine, electrical), but technicians will have varying degrees of proficiency in each. your vehicle will go to a single technician or team of technicians to complete as much of the work as they can. rarely does a service call require an overnight stay any more, because the engine guy is backed up by a team of generalists. now an argument could be made that the service advisor is a better analogy to the ba. i argue that when the problem is complex, the customer suffers from an 'expert' translation. a good advisor offers tons of communication about where the work is and when the customer can expect to be done. they may also advise on trade-offs so the customer can decide to only do what needs to be done now and return later for the rest.

what are your thoughts on the matter? should ba's be more integrated and more technical? to what extent? how can the customer benefit from a more agile business analyst?

"success is the goal and is deterministic, exercise those actions that increase the opportunity for success. the rest will happen naturally..."

i am a marine, husband, father, brother, son... i exercise leadership on a daily basis. deliberate and intentional leadership building and execution is not the norm for many organizations i've been a part of. most expect it to occur because it's something you "have" or obtain by "proximity". managers are expected to be great leaders because of title. leadership has been decomposed into specialized definitions for use in specific scenarios. seems an insurmountable set of obstacles. i'll agree that there are different kinds of leaders and leadership styles that are more appropriate and effective given the individual and context. this is especially true in agile development teams.

the position of leadership is typically described as someone forging the way, as an ability to influence a group toward a goal. this has been interpreted as either being able to keep ahead of or setting the pace for the masses. i suspect many have experienced this form of leadership. most may even agree that this works. my experience is this is temporary, inconsistent, and accidental. here are a few principles i keep in mind as i hone my leadership capabilities. these have been in practice for many years by many great leaders.

marine corps leadership principles: (slightly modified)

• know yourself and seek improvement: everyone has their strengths and weaknesses. know what yours are. exploit your strengths and improve your weaknesses.
• be technically and tactically proficient: before you take on the task of leading, know or have experience in the domain you expect to lead. respect is the reward for competence.
• know your team and look out for their welfare: this is important. know your members. create a safe environment for both failure and success.
• keep your team informed: communication is key. provide enough information to do their job intelligently and to inspire their initiative, enthusiasm, loyalty, and convictions.
• set the example: set the standard for conduct by personal example. if your standards are high, expect the same from your team.
• ensure the task is understood, supervised, and accomplished: this goes back to communication, creating a safe environment, and setting the example. be clear and concise, speak to your team, not at them. allow your team to utilize their own techniques at times, while actively supervising.
• train your team as a team: teamwork is the key to success. insist on teamwork. train, play, and operate as a team. ensure each member knows his/her role and responsibility within the team framework.
• make sound and timely decisions: you should be able to evaluate, estimate, and make sound decisions based on your experience. this inspires confidence in the team. once you make a decision, stick with it, until you discover it's the wrong one. then don't hesitate to revise the decision.
• develop a sense of responsibility among your team: members that accept tasks and are given the authority required to accomplish the task builds trust among the team. trust demands responsibility toward the team goals. this becomes a self-feeding mechanism for high performance.
• employ your team in accordance with its capabilities: seek out challenging tasks for your team, but ensure your team is capable and prepared to successfully complete the tasks.
• seek responsibility and take responsibility for your actions: actively seek out challenging opportunities. own the opportunities you are given, including everything your team does or fails to do. never allow another member to own failure due to your mistake.

So, I know what you are thinking.. Has he lost his marbles? What on Earth does a good credit score have to do with all things Agile project management related? Actually, I would argue the two are more tethered than one might imagine. In fact, the two are nearly synonyms. Allow me to explain.

From a very early age we are taught to save for what we want and spend only for what we really need, yet more and more young people are being introduced to the concept of credit cards. Colleges are allowing creditors to offer students exclusive accounts without educating them about the risks. Often they don't see the warning signs, and don't understand the longterm ramifications until they are in over their heads.

Every agile team has been issued in essence a platinum credit card. A card with no limit that they have been instructed to use wisely. Even with this as a consideration, cardholders still spend far in excess of what would be considered a reasonable amount. This is done under the premise that as long as they meet the minimum required monthly payments, that the debt will eventually go away.

Realistically, however, when making only the minimum monthly payment, the debt almost never goes away and in some cases even increases! How can this be so? This is the often overlooked concept of compounding interest. Even if we meet the obligation the best we feel we can, the debt continues to grow in size and severity until we become a slave to the debt. How do you identify that you have become enslaved by mounting technical debt? In an Agile environment, there are signs of debt overextension:

• If quality in the current product or project is continuing to suffer and the teams are never reaching a point where the existing bug log is diminishing, they are suffering from growing technical debt.
• When developers are drained because the QA process takes far longer than it should, and the development team calls for a better process to handle testing, this is a sign that technical debt could be nearing a breaking point.
• When the product is nearing release and only the absolutely required test cases have been addressed, technical debt could be an issue.
• When the customer is enraged that the product does not perform in an expected manner, that also can be tied to increased technical debt.

Now that we have identified a few of the signs of technical debt, let’s talk about what we can do to address this before it gets out of hand.

The first required step to get past any growing debt cycle is to identify each creditor and the amount you owe each one. Once each has been identified, you need to communicate to each one about your plan to eliminate each debt in a concise and planned way. Anyone who has ever dealt with a creditor knows that one of the most difficult tasks is convincing the creditor that they will need to wait until you have paid other creditors and are in a position to pay them their share. The same holds true with stakeholders. We need to help them realize that we will focus on their project and all of the new features and enhancements as soon as possible.

In the real world, this means letting the customers and stakeholders know that at the risk of slowing down new development and enhancements on current or future projects, the debt must be addressed. This news is never easy to deliver, and people are never happy to find out there will be a delay. However, they are forever grateful once all is said and done and the Agile development project turns out all the better because of the addressed debt. In fact, once the dust settles, the key stakeholders will be even more thankful to have a product or project that exceeds their expectations.

The next key is negotiating what is reasonable and customary. Often we agree to bite off more than we can chew. We need to only commit to what we can do, and make certain we are transparent in our work in order to allow others to see the benefit in addressing and taking care of our debts. Creditors will never take you at your word if you make promises and fail to deliver. As part of the structured repayment program, you need to meet all obligations.

Even once all of this has been done, you need to realize that your credit score does not instantly increase. It is through consistently meeting your obligations and eliminating debt over time that your creditors will deem you responsible and extend credit to you. This change does not happen overnight and trust is something that needs to be re-established as soon as possible with all key stakeholders on the project.

Another consideration is that we need to only focus on the debt that is not forgiven. Corporations do not embrace the concept of technical bankruptcy. There is no debt scrubber that automatically enables agile teams to eliminate all debt and re-structure. Once an organization has been burdened with debt, it needs to work to remove the said debt. The keys to success are simple:

1. Act NOW!
2. Identify key areas for repayment.
3. Enable testers.
4. Stop forward work as needed.
5. Make commitments and keep them.
6. Remain transparent.
7. Avoid additional debt at ALL cost!

The lesson learned is that debt is easy to build and hard to eliminate. It takes grit and determination to be successful in the quest to eliminate or drastically reduce debt. As mentioned earlier, the key is to have a plan and stick to it. Snowball to eliminate debt and make certain everyone can see and relish in your success. Reading this blog post could be the first step towards your organization's success.

Call me Captain Obvious, but the airport needs a runway. After all, would an airport be an airport at all without one? Even people who fly crop planes will profess that they need a sound place to take off and land from.

I have come to notice that on more than one occasion, Agile shifts its focus toward all that is happening now without regard for all that will be happening soon. Many teams even choose to forego release planning, as it does not provide the immediate and tangible reward that organizations may be seeking. So how do we continue to focus on the now while laying the foundation for the future?

The reality of it all is that at some point in the process, we need to put our faith in people and know that what we are asking for will be accomplished. This does not, however, mean that we should not be well prepared.

Well, we can certainly begin by going back to our airport analogy. Just as we encounter in travel, some airports are more pleasant to visit than others. Even with a safe place to take off and land upon, there is still more to making a great airport. Amenities often make the difference between desirable and dreaded places to stop at on your way to the destination. In an Agile world, this is really much like a release plan. Some are more smooth and others are very rough. When we focus on both the quality of the delivery and arriving on time and under budget, we can draw towards always taking the best path to reach the destination. The best path is often a combination of the one that ensures safe arrival and smooth delivery.

If we knew a certain flight path consistently provided undesirable results, we would try to avoid it. Yet knowing all of this is true, in a software development world, we often find it hard to adjust even if we have been down the path before. What do we need to do to act in a responsible way and make certain that we are doing what is best for the team, release, organization, and end user? How do we go about making certain the key people are in place to make reaching the final destination an enjoyable venture? Who do we turn to when we need to verify not only that the runway is there for takeoff, but that we can plan on all being for a safe arrival?

1) Fly often! The more frequently we fly the routes, the more familiar we become with successful delivery.

2) Plan ahead for landing! Frequent conversation with the control tower helps us land well every time.

3) Never procrastinate! Do not put off doing what is right!

4) Deliver early and often. It is the only way we can course-correct.

There are certain distinct steps which we can follow to help us make certain the takeoff, flight, and landing go off without a hitch.

1) Identify key resources that will be able & responsible for ensuring the underlying architecture is in place before taking on & committing to the work.

2) Learn to inspect & adapt, allowing you to follow those routes that have the least turbulence.

Agile project management and application development should be an easy win for all involved. It is not rocket science to get it all put together, we just need to focus and make certain the runway is indeed in place for us.

Teams ultimately rely on someone out there to have foundational measures in place for them to build upon. Many argue this is the role of the Agile development manager. Other organizations with a more formal release structure actually build a agile project release team that focuses solely on getting the project built and out the door. In this case, the release manager would be the responsible party. What many small to mid-size organizations that do not practice formal release planning techniques fail to realize is that although no formal role exists for the party responsible for launch, the role does still exist!

Indulge me and picture if you will for a moment that we were all preparing for the space shuttle to launch. I have visited many organizations who have proclaimed that the runway needs to be part of the actual project, or in one case, that the runway is someone else’s responsibility. I went on to ask if they would feel the same way if they were in the airplane at 32 thousand feet when they learned that the airport they would land at did not bother to build a runway.

The analogy to practicing agile development has been likened to building a plane while it is in the air. There is even a YouTube video of this process. My question to you remains, how important is it for our airport to have a runway to take off and land upon? Who is responsible for making certain the runway is in place within your organization? After all, without a sound architectural runway, where will your projects take off and land? Who is ultimately responsible for establishing the foundation and making certain all is in order and integrated when it is time to release? Who holds the keys to the kingdom when it comes to making certain all that we build rolls out according to planned expectations?

Many people in the Agile software development community believe that the problems they are facing within their organization are unique to them and their situation. After traveling the globe and listening to groups of all shapes and sizes, I have determined that many of the roadblocks to successful Agile development and implementation are similar in nature from one organization to the next.

Today, consider it my gift to you to let you know that not only are you not alone in what you are facing, but many other organizations have taken steps to improve the software development process and the way process by which it is delivered.

Whether you are brand new to Agile in general, or if you are doing an Agile Scrum or Agile XP hybrid, teams have walked this path before and here is what has been identified as the core list of problems they face. Let's just call it the top 3 roadblocks to special delivery: 

Coming in at Number Three, Lack of Established Definition of Done (Accountability)

Teams need to take the time to discuss what the differences are between development complete, test complete, done, and final acceptance criteria has been accepted. You would be amazed how many organizations struggle with the lack of this definition and the problems it causes when people figure out that done is not clearly defined and it drives people to work in silos. Lean Software Development and or Kanban Software Development have made attempts to address this issue by establishing clear work in progress limits. The team needs to clearly understand that done is done and what level of expectation has been set for them.

Not too far behind at Number Two, Inability to Accurately Estimate and or Forecast at both the Story and Task Level

Let's face it, developers HATE sitting in meetings. They especially loathe meetings that take them away from the coding world to provide estimates that only are useful to the business. We need to find the most efficient and accurate means for people at all levels to estimate, make certain teams agree to the standard, and understand the importance of the why behind the what. Why we estimate and the value it delivers should drive people in any role to use efficient Agile project management software to capture the data in a format that makes it as easy as possible for everyone to be consistent and get back to work.

And finally, the Number One Problem teams face when trying to deliver, The Product Owner or Product Ownership Cloud lacks the Ability to Precisely Slice & Dice Information From a Traditional Project Management Document Into Meaningful User Stories.

The role of Product Owner has been so overloaded in the Agile world that many times people do not get the picture of just how much responsibility and accountability ride on this role. In Scrum, I have heard these people referred to as the 'single wringable neck'. This is the person or group who needs to consider value to the organization, need of the customer, & perceived level of effort and complexity to the development team, and with that data need to organize and compile a list of meaningful items to a group of wizards who will shred them even further into tasks. I do not care who you think you might be, this role is NOT an easy one. I am of the opinion the Product Owners need the greatest level of training in order to help them understand why agile, how agile, and be armed with what they need to be successful. 

So as you are sipping eggnog and eating fruitcake, remember that the success of the Agile project, or the special delivery, lies in your hands.  

When speaking to people who find Agile, or more specifically, iterative development, a difficult concept to understand, I tend to use the analogy of human beings performing in an Agile fashion. Most of us live in 24-hour iterations in which we need to complete certain requirements; Sleep, eat, work, take the kids to school, etc. Most people can agree that we are completing most of these activities, and those of us who claim to eat and breathe agility like to brag about how we run our personal lives in that manner.

But now I have a confession to make. I thought I was living iteratively, and to a certain point, I am. I am one of those who doesn’t like to get up to do the chores, but once I am up, I do not stop until that chore is completed. I have noticed a large discrepancy in this notion, however, when I looked at my clothes dryer earlier this week. It is literally piled up with 2-3 loads of laundry neatly stacked on top. Oh my, my laundry did not achieve done-done status! I was not so much devastated at the fact that I am digging through a neatly piled heap of clothes when I get dressed each morning, but rather at the notion that I have been proud to think that I AM AGILE, but in fact, I have failed. So now, I find myself splitting requirements. A friend asked what I did last weekend, I started to say that I did laundry, but I felt that I could not take credit for work that is not done. Bummer. Back to the whiteboard.

If a concept in your software is not actually represented in your code, does it really exist?

As a simplistic example, if your customer or user thinks of your application in terms of "notes", but there is no code that describes anything called a "note", that concept is not represented in your code.  One significant thing an agile development team can do to make a code base more agile (supple) is to ensure that there is a high degree of correlation between how we describe and think of our software, and how it is implemented.

This is another way of looking at Ubiquitous Language, a fundamental concept of Domain Driven Design.  Oversimplified, the nouns and verbs of your system need to be aligned with the nouns and verbs used to talk about the system.  But even more essential is the alignment of concepts: words may need to be translated, but it is infinitely more complex to reconcile disparate concepts.

Why is this important?  For one thing, aligning the implementation with the picture in the customers' heads reduces a lot of friction in communication while developing features.  Additionally, a system that doesn't reflect the mental model that bore it will eventually prove rigid and resistant to new features to: the customer may want something that, while perfectly compatible with his idea of what the system does, is impossible to implement.

When a concept changes dramatically for the sake of a feature (e.g. a major change or addition), we expect it will be a large effort.  However, if the concept doesn't change much, but the code does, it's an indication of a departure in the code from the concept.

How does this happen?  Basically, the developer conceives different abstractions than the customer, and these are never resolved.  This can be caused by poor communication, insufficient design or premature generalization.  Most often, we are driven as engineers to provide value by 'translating' the customers needs into implementation instead of fostering and maintaining a ubiquitous language.

Then, down the road, when the customer expects to extend or enhance a concept that's poorly represented, there are no cohesive parts in the code to target.  As a result, the developers find themselves doing "shotgun surgery" all over the application to try to get the application to behave as the customer expected.

The value we provide between concept and delivery is not a one-way translation: it's a dialog.  Moreover, the apparent simplicity of this idiom should not cause us to pass it over for more complex and seemingly sophisticated solutions.

I am currently in my second year on the Agile Alliance board. We meet face-to-face four times each year (including at the annual agile 200x conference) and September’s meeting was planned for London. Coincidentally there was also the UK Lean and Kanban Conference happening in the days leading up to our board meeting. This meant a good chance to get to London a little early, get acclimated to the time zone and take in some sessions. VersionOne was also a sponsor/supporter of this conference so it was good for me to be there to "represent" but I assumed more of an attendee role than anything else.

As I said in my intro to the whole “fall journey” thing, there are a few people within this community that would like to differentiate themselves right out of the broader agile community but to me this seems more about “branding” than anything else. At its core, this community is a group of people that primarily are experienced agilists - whether they originate from teams using a scrum framework, eXtreme Programming, hybrid or other agile methods - but have moved towards something “new” to further the improvement of their software delivery teams. (Unfortunately, the branding/differentiating efforts may be doing more harm than good with people and teams that have just begun exploring a transition to lightweight methods.)

The conference was very interesting in that this was a fairly small group that had people very passionate about Lean thinking and the use of Kanban - Sometimes one or the other and to a lesser extent, both. There was some fairly divisive commentary by some of the community ‘leaders’ with respect to “Agile” or “Scrum” but this was mainly restricted to the consultant side of the house so I will put that down to the whole branding thing.

I find it really humorous when people talk about “doing” agile, I heard this a few times in regard to moving to Lean/Kanban from “doing agile”. I must have missed the point when agile development became a defined set of practices from which one cannot stray instead of an umbrella term for various methods and practices. Also interesting was the ability by many to use the words Lean and Kanban interchangeably. This bugs me in the same way as when people use the words Agile and Scrum interchangeably. These terms are related but not the same.

Since the entire Agile Alliance board was in town, the Agile Alliance sponsored a reception at the end of the second day for all the conference attendees and Agile Alliance members that happened to be in the London vicinity. This gave the Agile Alliance the opportunity to show its support for the Lean/Kanban community and for discussions with board members to learn about what the Agile Alliance has been up to and where it is going in the next few years. These receptions are something the board began doing at each face-to-face meeting starting in Paris last January. This gives the board the opportunity to interact with communities around the world, getting feedback and input into our overall roadmap so that we have a better chance of serving our community effectively. (The next reception coincides with the Agile Alliance board meeting in Atlanta. It will be Wednesday December 16th @ 6:30pm at the Marriott Perimeter.)

For me, like most conferences I attend, the best parts were outside the sessions - in the breaks, around the dinner table and at the pub in the evening. This is where practitioners get passionate, where the real meat is. There is less divisive talk and less concern about “my brand” over “their brand” – or at least when there is, it isn’t veiled and you can call people out on it! There is always lots of discussion about what is working, how people got there and more importantly, what is *not* working. Every traditional conference begs for these types of talks: what went wrong as opposed to a big [insert your fave method/practice] love-in. In a more personalized atmosphere people seem to be more open to discuss their experiences in detail. As a side note, this may be why open space events tend to be so successful in the eyes of attendees. It is more about sharing experiences that are open to discussion and debate. I will have more to say about the open space thing in a later post on the Boston AgilePalooza.

Check out these Lean & Kanban resources…

• Jeff Patton debriefs his Kanban session during the AgilePalooza Openspace in Boston on YouTube.
• Jeff does a deeper dive with the article on Kanban Software Development Oversimplified on his site agileproductdesign.com.
• "Lean thinking" is a little more than a blog post, presentation and certainly more than you can fit into 140 characters or less…check out this really good Lean Primer (46 pages & 957k) by Craig Larman & Bas Vodde.
• Limited WIP Society - www.limitedwipsociety.org
• Lean Software and Systems Conference in Atlanta - April 21 - 23, 2010

The fall season has always been crazy for conferences and community events. The main difference this fall was that I got to hit the high points (IMHO) in person.  This meant a serious amount of travelling – well, more than usual for me. My “excellent adventure” saw me log over 30,000 miles flown traveling to London for an Agile Alliance board meeting and the Lean/Kanban conference, Munich for the Scrum Gathering, Boston for AgilePalooza, back home briefly for Agile Vancouver’s 4th annual conference and then a quick trip to Orlando for Agile Development Practices. 

I am going to write up some posts covering each event but for me the most interesting part is thinking about the trips as a whole. I touched a really good sampling of different sub-communities that make up the broader agile ecosphere.  I got to meet tons of new people and see a lot of friends as well.

From the Scrum Gathering, where huge changes are happening within the Scrum Alliance, to my local user group conference in Vancouver that saw over 200 people come out to an event organized by a handful of volunteers, all these events are really about one thing: people looking to improve their craft and how their organizations deliver software.  And as much as the more commercially inclined within the Lean/Kanban community would like to differentiate themselves right out of the agile ecosphere, they are right in there helping to lead what agile is all about: change – constantly improving the way software teams work.

"i'm not concerned with your liking or disliking me... all i ask is that you respect me..." ~jackie robinson

i'd like to spend some time talking about respect, or organizing for respect. specifically in context of a collaborative vs cooperative agile team environment. i think this context will provide enough familiarity for most while providing a point of reference for others.

respect [verb]: to show regard or consideration for: to respect someone's rights. ~(dictionary.com)

can cooperation occur irrespective of any individual's respect for another? imho - 'yes'. to effectively cooperate with others, you usually require a binary response toward those you need to cooperate with. 'can i or can't i work with him/her?' or 'do i like or dislike him/her?' the more positive responses you have towards the others, the more effective the cooperation will be. should conflict arise among this kind of team, the results may vary based on the dynamics:

•  the majority influences the minority [mob rule]
•  a group reaches consensus to avoid conflict [groupthink]
•  the minority remains silent to avoid conflict or being ostracized [spiral of silence]

 ~ (wikipedia.com)
 
there are other plausible results, but so far, none seem conducive to 'me' thinking that leads to 'we' thinking, or inline with a team environment where respect exists for others. that is not to say respect does not exist on a cooperative team, just that it's not necessary or required. agile teams organized in this way will typically find guidance from a single source, either an individual or a sub-group of the team, utilizing a fraction of the knowledge and skills to execute on the goal(s). total ownership may not exist because a portion of the team conceded in some way. quality suffers in every way: definition, analysis, construction, and testing.

on the other hand, can collaboration occur irrespective of any individual's respect for another? imho - 'no'. i think respect is essential for collaborative agile teams. collaboration incites conflict. reasoning and results are challenged to gain a shared understanding of the goal(s). input is provided by all, digested, and actioned based on gained knowledge. those involved participate, challenge, and compete with one another to gain consensus. the process is facilitated for, rather than guided toward, progress. there simply exists a certain level of respect to accomplish this kind of team environment.

successfully collaborative agile teams require a level of respect not essential for cooperative teams to accomplish a similar set(s) of goals. i think respect is present for each team. in a previous post on 'pride' i mentioned 'me vs we thinking' and how the subtle differences have contrary organizational systems with impactfully differing natural consequences. collaborative and cooperative teams are contrary organizational systems. 'respect' is a natural consequence of one and not the other.