"Selflessness gives one center.
Center creates order.
When there is order, there is little to do."

From the Tao of Leadership by John Heider, adapted from the teachings of Lao Tzu

Series: Barriers to Organizational Transformation

The Barrier
This is the first post in the ‘Barriers to Organizational Transformation’ series and it is the Friday before Memorial Day so I thought I’d start with something light but important: Those corporate security policies that disallow openly displaying information on walls, hallways, etc.

The Effect
As you can imagine, the problem with these outdated and frankly useless policies is forbidding to put up any vital visual management tools (e.g., task-boards, burn-down charts, defect rates, etc.), architecture diagrams, meeting boards, etc. and have to erase everything from whiteboards at the end of the day.

I have actually been present at sites where we just got through getting the team bought-in and excited about the idea of transparency though visual indicators and information radiators, agreeing upon and constructing the visual information radiators and installed them and then promptly being asked to rip them down by security the VERY SAME DAY! This was not just a blow to morale, but set the transformation back since it was one of the pilot teams. Unfortunately, I see this barrier in almost every client I work with.

The Reason
The reason behind this policy is that they do not want vital information to be seen by someone on the outside, especially corporate spies. While I can understand this, consider the amount of security that needs to happen before someone can even get in, starting with a badge that has to be authorized by a guard or an electronic system. I have seen this policy enforced even when there were 3 separate locked doors standing between the would-be ‘spy’ and the information.

Consider a couple of things:

1. Would someone who can breach physical security not be able to get to your wiki, most of which are available on the intranet w/o a username and password?
2. Is the fact that John Q Engineer is blocked on task #3 on day 5 of the sprint actually useful information? Will your competition’s CEO look at that information and say, “My plan to take over the world is coming together nicely, now that John is blocked on task #3 ”?
3. Even if it is a guest or a customer, would it really matter if they looked at that information?

The Solution
Fortunately, the solution to this, even in the some of the most rigid environments, is reasonable simple (compared to the other barriers, anyway). Meet with one of the managers (the highest-level manager you can get to) of the security group in your physical space and go over the use and importance of these information radiators with them. Explain to them what they are and why they are needed and why the information isn’t harmful and they will usually grant an exception. In many cases, there is an exception form that has to be signed by a manager or director within your group.

Sometimes they will ask you to obfuscate some of the information or ask that just a small part not be displayed or taken down and locked up when not being used. We concede to some of these, especially architecture. Many of those are easily resolved by doing what we need on the whiteboard, taking a high-quality picture (or set of pictures) and displaying them in a secured site.

I once had one of these meetings where they said everything is allowed to stay up as long as you write the codename backwards. We had to laugh at the fact that we have a codename for a codename. Like someone from the outside is going to look at it and say “utkubmiT? What’s that? Darn-it! My plans are foiled once more!” None-the-less, it was a small price to pay and we complied.

Do you have any war stories with this barrier? Please share. We’d love to hear them.

Series: Agile Transformation Anti-patterns

I remember that day like it was yesterday. The click of the camera, the awful picture, the waiting for what seemed like hours and finally, that moment where I was handed, still hot off the lamination machine, freedom, emancipation, liberation – or as you may call it, a driver’s license! That was one of the most memorable moments of my life (don’t tell my wife). And it was hard-earned! All those days of repeatedly practicing K-turns, parallel parking, mastering the art of the 4-way stop and just generally surviving driving in New Jersey! All those skills that we can now exercise in our sleep (but really, really, shouldn’t) weren’t as intuitive or simple back then. It took a lot of practice and more importantly, coaching when we were learning.

Even though I knew that Driver’s Manual inside-out and received only one question wrong on the written exam (which I still don’t know the answer to, btw), I would never dream of getting behind the wheel of the car with just my learner’s permit and a vision to one day own that 1983 Honda Civic. I needed a coach sitting beside me, working with me and guiding me as I was driving. It was nearly impossible for most of us to go directly from passing the exam to the road test. I needed that guidance and practice in my own car.

Getting a driver’s license is the same learning model as becoming a doctor or an Agile practitioner:

• Training and reading build knowledge
• Applying that knowledge so that the desired outcome can be repeatedly achieved is skill
• Repeated application of that skill in different circumstances forms experience

This process, unfortunately, is lost on most sponsors who cause one of the biggest transformation anti-patterns: Coaching not necessary – the thought that one 2-day course or just reading some books will instantly create a set of Agile practitioners. It takes time, dedication, experimentation and most of all, coaching, from an experienced coach that is either in-house or external.

Would you trust a lifeguard who received her certification on the Internet based on an online exam and no practice? What about a surgeon who has never had any internships, residencies or any hands-on experience? Would you trust him to operate on you? I understand that a newly trained Agile practitioner isn’t going (usually) to kill anyone if they miss an iteration goal or their retrospective goes sour but the concept is still the same – getting results from an Agile transformation takes experienced practitioners. Training, no matter how good, will only build knowledge. Applying that knowledge so that the desired outcome can be repeatedly achieved is skill. Repeated application of that skill in different circumstances forms experience. One cannot go from knowledge to experience and one cannot build skills in the classroom. To achieve the desired results from a team, it takes time to nurture and grow them, and that includes coaching along the way.

Don’t get me wrong. I’m not out to say that agile practitioners aren’t bright and can’t apply what they have learned in the class or book within their own environment. But consider your unique environment – your corporate culture and the quirks that are yours alone, your current environment, infrastructure, leaders and their leadership style, organizational structure, incentives, and so on. There are so many parts to the makeup of an organization that sometimes it isn’t obvious how to apply what they have learned. A 2-day course (or even a 10-day course) cannot cover all possibilities. And what about scaling? The more teams there are (esp. distributed teams) the more the challenges the newly trained practitioners face. It gets overwhelming, especially for new practitioners.

In addition, please don’t misinterpret my views about classroom time. I have been an instructor for years. I love teaching and I will be the first to point out that classes and books are an essential start. They add the knowledge which is required to start the journey. However, it will never build skills. Application of that knowledge in your own environment will do that. And the more complex the environment, the harder it is to apply that knowledge. Coaching from someone who has done it before and seen many of the pitfalls the team may be headed for will work with them to navigate the rocky terrain, teaching them within their own context and arming them with the tools to apply that knowledge to make wise decisions. In essence, the coach’s job is to work themselves out of a job. Repeated application of that skill in different circumstances forms an experienced practitioner who, by the way, is your next coach.

Don’t try and save the cost of some coaching and try and get everyone trained instead, thinking those will bring about results. Instead, consider picking a smaller subset of the whole who can be trained AND coached in their own environments, who, because of the coaching, would come up to speed faster, avoid common mistakes and would ultimately coach the next generation. Consider what you may consider an expense may actually be an investment, which will pay dividends for years.

Series: Agile Roles and Responsibilities Series

Many pundits preach that the agile organization will not have managers – that teams will self-manage and can carry out all responsibilities of traditional functional management. This includes HR responsibilities, major conflict disputes, etc. “The team is self-managing, which includes all management responsibilities,” or so I keep hearing. Call me a heretic, but I’ve never subscribed to the scalability of this model. For most large-scale (esp. global) organizations, this is not a reality. Not only are functional managers not going anywhere, but they are, in-fact, essential to an organization’s transformation to Agile practices. However, their roles will need to change. Whether they embrace or reject this change could mean the difference between success and failure going forward.

To highlight the differences, let’s lay out the major responsibilities of a traditional functional manager:

1. Handle HR functions (e.g., Hire and fire/lay off, harassment, physical violence, larger-scale verbal assaults, etc.)
2. Champion causes/break down barriers
3. Maintain standards (quality, technical, ethical ) across the different teams
4. Develop employees technical and other necessary skills
5. Create, manage and restructure cross-functional resources
6. Execute performance evaluations
7. Set up work processes (esp. for their team)
8. Break down and assign tasks
9. Project manage the team (usually with a gigantic Gantt chart and a weekly status meeting)
10. Be responsible for the team’s commitment and deliverables

(I’m sure I could have listed another 20 responsibilities but I tried to focus on the top 10. If you feel there are important responsibilities I didn’t cover and a through on whether an Agile manager will retain or relinquish them, please feel free to list them in the comments.)

So what in this list changes? That can be answered by the overarching mental model: The Agile management (as a whole)’s mission is: To do what needs to be done to create an innovative, flexible and continuously-improving environment that will allow teams and Product Owners to succeed. This means creating an organization that is capable of executing Product Backlog changes at any time (including at the 11th hour) as efficiently and with the highest quality possible.

To accomplish this, Agile Managers would still handle responsibilities 1 through 4 - traditional HR functions, develop employees, set up and maintain standards (optionally with the help of Agile technical leads) but will hand over the their project and process management responsibilities (given in steps 7-10) to the ScrumMasters (if practicing Scrum) and feature teams.

But why give up those traditional responsibilities of ownership, assignment and management of tasks? Several reasons come to mind (feel free to add to or contest these):

• Allows the team to own their commitment, and just as important, own it as a team
• Allows the team to focus on the greater iteration goals instead of just their individual tasks
• Empowers them to self-improving

Many managers are concerned this hand-off of responsibilities diminishes their role. I feel it is quite the opposite - that it focuses their role and elevates it to a more strategic level. Instead of being consumed by tasks that teams are perfectly capable of performing themselves (albeit, teams usually need help at first), Agile Managers will now work as a group to see which changes need to happen organizationally – those that we never saw before or saw but were too busy (or un-empowered) to do anything about. This change will let them focus on:

• Setting up and managing cross-functional teams
• Creating and managing needed infrastructure (e.g., testing platforms, continuous integration, etc.)*
• Break down organizational barriers, usually raised by ScrumMasters and teams through Daily Scrums and Retrospectives or similar events
• Create and manage technical standards across the organization (with the help of teams and technical leads)
• Creating, training and supporting change agents (e.g., ScrumMasters) within the organization

*Note: I don’t mean to imply that the managers code the infrastructure themselves (although, they are free to do so if they want). I just mean they will look at the largest gaps and create internal teams to work on them as needed.

Item 5 deals with the creation, allocation and evaluation as teams. The Agile Manager still own this responsibility but performs it very differently than they would have traditionally. They don’t design the organization by architecture, layer or component (e.g., the GUI team, OS team, driver team, database team, etc.) but rather by vertical features. Additionally, a set of Agile Line Managers should treat all resources reporting to them collectively as a pool of resources where teams can be “pulled” from, instead of individual resource ownership. This means that Agile Managers will collaboratively assemble the best teams for a group of features and not just have teams by virtue of reporting structure. (I will follow this up with a deeper post on this topic).

Last in the list is item 6, which, like item 4, is also a transformed activity owned by managers. Managers are still responsible to perform evaluations but they will do this based primarily on the team’s performance rather than an individual. It is also a great practice to do this as a team of managers, instead of individual evaluations. (We’ll debate the right performance measures as well as the idea of abolishing performance reviews on another post).

Finally, it is up to the managers as a whole to set the culture to continuously improve and continuously experiment to do so. An Agile manager’s motto should be “It’s OK to Fail”, as long as we do it fast and learn from it toward the right goal. They know that the phrase “I don’t know” is a much better phrase than an uncertain answer based in no data or reality given because one is expected.

The fact is that Managers make or block Agile transformations. There is a lot of talk of top-down leadership and bottom-up push but the managers connect these domains. They are the ones that can greatly accelerate or critically hinder a transformation. Which camp are your managers in?

One of the most misinterpreted and misapplied terms in our Industry is the term ‘empowered’. I hear it used over and over from organizations that are new to Agile concepts and have usually know just enough to be dangerous - and dangerous they become. Although I’ve seen this term misapplied in many different roles, it is usually my experience teams that are the biggest culprits, and that’s who I’ll focus on in this blog. Using it more like the term ‘anarchy’, the term ‘empowered’ misused as a reason to get away with everything from reprioritizing the Product Backlog to missing iteration goals. This behavior is one of the most disruptive forces in an Agile transformation.

I thought I’d shed some light on that term and where the term ‘empowered’ does and does not apply.

Let’s start with the definition of empowerment:

em•pow•er•ment [ɪmˈpaʊəmənt]
n
1. the giving or delegation of power or authority; authorization

When it is said that “teams are empowered”, they are given certain authorities where management approval is no longer necessary. This authority is over HOW they work, which includes (but isn’t limited to):

• Own the delivery of an integrated, high quality vertical slice
• Creating, owning and managing the Iteration Backlog – the list of tasks the team collectively needs to complete in the current iteration toward the iteration goals
• Owing their own work-processes – how members of the team work together within the team. This includes, but isn’t limited to, setting up their own meetings, rules of conduct, team norms, etc. – basically those processes that are needed to work effectively as a team
• Being able to create and own their architecture (this may be limited to architecture of a particular section for large-scale development)
• Own their technical practices – be able to practice paired programming, Test-Driven Development, Continuous Integration, Refactoring, etc. without Product Owners or managers telling them not to

However, there are bounds to that empowerment and teams that exceed those bounds are teetering on the edge of:

an•ar•chy ( n r-k )
n.
1. Absence of any form of political authority.

Empowerment turns into anarchy when we here statements like the following thrown around by team members - “We are empowered to...”

• “Change the features in the Product Backlog because we didn’t like what’s there”
• “Change the order of the Product Backlog because the high priority items are boring”
• “Not help our managers, other teams or other colleagues outside the team because we are empowered not to be interrupted” Aside: I actually knew of a team that enclosed themselves behind locked doors so they wouldn’t have to speak to anyone between iterations. I understand empowered not to accept scope creep but not letting anyone even ask a simple question is ridiculous.
• “Deliver nothing!” I knew of several teams that delivered 0, nothing, nada, zip, zilch, you get the picture, for multiple iterations because they told the Product Owners (who weren’t trained, btw) that “the teams were now empowered to choose their own work.” Ummm, no.

So what’s the line between genius and madness - between empowerment and anarchy? Two simple mental models that will act as your litmus test:

1. Product Owners are empowered to decide WHAT features the teams will work on and in which order
2. Teams are empowered to decide HOW they will work on delivering those features.

Two notes to keep in mind:

1. I don’t mean to imply that there is no collaboration but rather final authority on both sides. Teams are welcome and encouraged to give input on priorities but the final decision is the Product Owners and the teams are NOT empowered to override that priority. Product Owners, etc. are welcome to give input and best practices on task breakdown, max. number of hours per task, technical norms, technical practices, etc. but the final decision is up to the team.
2. When you have multiple teams, there may be organizational norms and best practices that the team may have no authority over. It is up to management and ScrumMasters to collectively determine on a case-by-case basis if those are helpful or barriers.

The whole point of these particular empowerments are to create the most innovative and effective organization. It also focuses the different roles to accomplish their goals efficiently. Be wise and watch out for words that are thrown around without making sense.

I’ve been noticing a disturbing trend lately where pundits, bloggers, and practitioners keep insisting there’s only one way to practice Agile software development, and it’s usually their way (go figure). I can’t tell you how many times I’ll read or hear about new Agile practitioners who asked a simple question on an online group or in a conference and hear a one-sided prescriptive approach – and worse, an extreme view that is so out there that few organizations can hope to do anything close when they’re just starting out. And if you’re not practicing certain techniques, which are usually the latest thing from Xaphod Bigbookauthor or Ima Agileguru, these extremists will just say, “you’re not doing Agile!” There’ll be a lot of citing this and quoting that and listing some definition of some practice in some book. If your team doesn’t match what’s on page 462 sub-paragraph 2, section D, you’re not Agile.

Have these people forgotten the meaning of the term AGILE? Or did they just never realize that Agile is not about the tactics but about the goals, the most important goals being continuous learning and continuous improvement? As Rod Belshee, a friend, client and tree-hugger put it, Agile is “about experimenting and assessing. A way to consider what we tried in this type of situation, the data on how it worked, and what to try next. In other words, we do not want Agile to become a rigid set of practices, but remain a way a thinking.”

Now, don’t get me wrong. I’m not poo-pooing the best practices or the work that many Agile pioneers have done that we as an industry have come to appreciate. What I am saying is those best-practices are getting turned into religion and that the zealots will have you believe that there’s only one way to do it right, that executing a defined set of these practices will make you ‘Agile’. If you aren’t practicing all in this set, you aren’t ‘Agile’. Like that’s the way teams and companies work…that one day, they’ll all just collectively wake up and decide, “Hey, let’s do all of this all at once.” And just like that, voila!, we’re in ‘Agile mode’. This type of dogmatism is not only misguided but leading many people who read and hear this to think that Agile methodologies and practices are not suited for them. More than 75% of the clients I have worked with had one of these dogmatists and had been told they couldn’t be helped. That, of course, wasn’t true.

One size (or set of practices) doesn’t fit all. We have to be the most Agile when it comes to how companies and teams adopt this way of thinking. Some are faster to move and some are slower. Some are passionate from the start and others need to see the value. With ones that are slower (and usually bigger), there are leadership, cultural, technical, process and many other dynamics that need to be overcome. They need a roadmap for migration that takes into account dozens of years of legacy (and usually hurtful) practices ingrained into their culture.

Not every practice has to be done when an organization first starts and not every practice is right for every organization. Practicing Agile means being agile in not only how we work but how we roll out these practices. I would say that a measurable goal (or set of goals) and the continuous pursuit of improvement toward that goal is a magnitude better than dispassionately executing practices because some book told you to do so.

Series: Agile Roles and Responsibilities Series

Anyone who knows me knows that I love ScrumMasters.  My family had to get used to the idea of being second in line, but they’ll get over it.  Why the love affair? Simple.  They are the organization’s change agents!  Their #1 role is to continuously create positive changes.  (FYI, if you thought that the role of the ScrumMasters is to be a simple project manager or task-master, read this first: ScrumMasters are not Task Masters)

They create positive change by:

• Setting up, owning and upholding the process of Scrum
• Ensuring that the process is followed by all
• Identifying, escalating and having barriers broken (this doesn’t mean they necessarily do the breaking)
• Teaching the process of Scrum to all parties
• Working with Product Owners, managers and the development team (including architects, testers, etc.) to evolve the organization
• Leading a team to increase their productivity (velocity)
• Facilitate the roles within the organization to work efficiently, effectively and most importantly, together
• Being enablers, problem solvers, and more…

The amazing thing is that the ScrumMaster role doesn’t call for any managerial authority over the team, Product Owners or other managers.    They lead by influence, not by authority.

Although SMs are an essential part of the team, they are not wholly devoted to just their team.  This means although the SM belongs to the team, they are not just there for the team.  If the SM is doing their job correctly and efficiently, they are working 1/3 of their time with the team to deal with team issues, break barrier, 1/3 of their time hand-in-hand with POs and 1/3 of their time with Management.   So with all this, when do they have time to code?  In my humblest of opinions, they don’t .  The ScrumMaster is a full-time role – but before you jump all over me, that is a different post and discussion.

When a team is newly formed, this balance will be shifted more toward the team but over time, new teams will be comprised of members that have done this before and not need to take so much start-up equity from the SM.   So, what are SMs doing with each of these three roles?  Helping them meet their goals. Removing barriers when possible and escalating barriers when appropriate.  Installing, teaching, upholding, and most importantly, evolving the process of Scrum within the organization toward the very concrete goal of reducing defects and increasing velocity (in that order) for the organization collectively (starting with their team).  This means working with the POs to complete the release plan, working with teams on iteration planning, reviews and retrospectives and working with management on what they need to do: Transform the organization into an agile organization that can move to the beat of the Product Owner (Yet another post). 

This, however, does NOT mean that SMs project manage.  The teams and Product Owners need to do that themselves. The ScrumMasters are ensuring that the release and iteration plans are being set up and helping evolve the process, not doing that work for the team.

I could write a book on the topic so forgive me if this bite size morsel is leaving you in want.  I will be filling in many of the gaps in future posts.  As always, I look forward to your comments.

One question I am often asked is “Does testing add value?” Many people who ask this question are development or Q/A managers who are trying to figure out how testing fits within an agile environment. My simple answer is: “No, it does not.” 

Now, before you get all half-cocked, I am not saying we should ship a product that is hanging together by dental floss. I am definitely not saying let’s just throw in more and more features and leave less time and resources to maximizing quality. I mean quite the contrary.

When I say testing has no value, I mean the time it takes to test a product doesn't add value to the end customer. Value, by this definition is "something that takes the form, feature or function that the customer is willing to pay for." Customers don't want to pay for testing. They want to pay for a high-quality product. To illustrate, let’s look at two different ways to develop a product:

1. Big bang approach: Spend a lot of time building and ignoring defects along the way because they will be addressed in the 'Testing' phase. Defects pile up, get more and more complex and worse, get more and more buried. The engineers/developers then, need to go in and spend most of their time finding the defects before fixing them. This is a lot of time and cost that has to be built into the cost of the product. This doesn’t even take into consideration the inefficiencies of bouncing the defect between the Q/A group and development groups. Customers pay for this necessary step but it adds no value to them. A good amount of the cost and time of finding and fixing the defects could have been avoided.

2. Alternatively, a savvy organization will adopt practices to build integrity into the product and test as you go in small batches. In fact, they will develop requirements AS test cases. The developers build to those test cases, which are objectively measurable and testable as you go. In essence, the developers allow the testing to drive development, not the other way around. This, of course, is the philosophy of test-driven development. The idea here is to build small, high-quality slices of the product and then integrate it in as soon as possible. Part of this continuous integration involves testing the whole as you go. If defects appear, they will most likely be caused by the latest addition. If this latest piece is small, the defect can be found and resolved easily.

A further step would be to avoid creating as many defects as possible by using best practices and quality principles during development. One more tool would be to borrow the concept of a 'WIP Cap' from Lean. This means that if we reach a set number of open defects in our database during development (usually 5 or less), we all stop, fix them and move on. It is much more efficient to fix them now than later when the product is more complex.

The second approach exposes problems in hours and days, not months later when different components are completed independently and finally integrated. It will create a higher quality product with severely reduced time in the end and thus cost and time to market because teams don't have to find and fix all these hidden defects that were created by ignoring them along the way. This is more valuable to the customer because they are spending most of their money on creation of features, not on finding hidden defects. Of course, even this approach will not be a 100% bug-free but industry metrics have shown defects to drop as much as 80% in a development life-cycle.

So is testing valuable to the customer? Still no. Is it necessary? Absolutely. However, by using good quality practices to build integrity in, let testing drive development, integrate in small slices and test as you go, the time and effort to test will drastically reduce creating a much more efficient development group.

It is almost guaranteed that when I work with new organizations, one of the first questions that comes up is “How does the development organization work with the Q/A organization?” This question is a stinker. A seemingly simple question actually is pointing out much deeper organizational issues that go beyond testers to how we see all roles within an Agile environment.

That question usually indicates that most managers are trying to force-fit Agile methodologies into the old organizational structure. This is not just inefficient, it is detrimental. When thinking about moving to an Agile framework, an organization must consider what we are delivering and how. Practicing Agile means delivering small, vertical slices of the product every iteration. Vertical in this case means a slice that encompasses a feature from the customer-visible front-end to the back-end and everything in between. 

The key mental sound bite here is that a slice isn’t done until the customer sings (with joy and praise, that is). To be done with a vertical slice, it needs to be developed, integrated and the whole product (up to that point) tested. To say a slice is done, means it is usable by the customer and is as close to shippable condition as possible. (I will have future posts on how to use this model with mixed software and hardware development).

The most efficient way to accomplish this is to reform a team from component-based teams into vertical teams. A vertical team is made up of all resources I need to finish that vertical slice. This may mean a GUI developer, the business logic fellow, the database expert, the network security professional, etc. – whoever is needed to complete the feature in its entirety. This also means that a Q/A professional is a part of the team, working hand-in-hand to create a high-quality increment. Developing even a small chunk and then ‘throwing’ it over to a separate Q/A group will not yield the efficiencies that well-practiced Agile teams boast about.

With that said, keep in mind that the Q/A professional’s role changes within the team.  We don’t just want to put a tester with developers.  We don’t want to create a situation where developers throw completed items over a mini-wall to have tested.  Rather, the developers themselves will do as much of their own testing as possible.  The goal is to create a team that has powerful skills to deliver the highest quality product.  The Q/A professional will be responsible for ensuring all test cases for that iteration are defined, mentoring developers on building testing skills, including how to think about, write and execute test cases as well as helping the team automate as many test cases as possible.  Just as they teach the team how to test, the team will teach the tester how to do simple coding for the sake of test automation.

Last but certainly not least, an essential part of the vertical team is the Customer – or at least the best representation of the customer that we have internally, usually a Product Owner. Unlike someone who furnished a book of requirements, expects delivery many months later and wants no communication in-between, a Product owner works with the team(s) on requirements, is essential in breaking them down vertically and works side-by-side with the team during the iteration planning and reviews. Product Owners may not necessarily be co-located but will answer any questions asked by the team in a matter of hours, not days or weeks.

To be truly agile, you need to plan, think, build on a feature-by-feature basis. To accomplish this most efficiently and effectively, the team needs to be vertical – have all the resources that are necessary to complete the features within the team. This includes, developers, Q/A personnel, Product Owners, documentation, etc. Pets, however, are optional.

Experimentation is the key to learning and continuous learning is the core of Agile and iterative methods.  A wise man once told me that we know the least about our product and the optimum process to build that product when we first start. I could never (or never wanted to) argue that point. When we are at crossroads facing an unknown path, experimentation lets us understand which avenue is best. 

Experimentation means to find that path wisely. Don’t get into analysis paralysis. Here are some suggestions to make your experiments a success:

1. Make your experiments iterative so that the lessons from the initial ones can be used to plan and create the next ones. 
2. Make your experiments short and tactical so that you can learn quickly about what works, and more importantly, what doesn’t work. 
3. Finally, and most crucially, an experiment that fails is just as important as one that succeeds.  The answer will guide you on how to proceed from that point. Don’t be tempted to think that a set of experiments that ‘fail’ aren’t a success. The experiments simply yielded an answer. 

If you have more suggestions on how to conduct a good experiment in your environment, feel free to post them in the comments. In addition, if you’ve learned something that changed the way you work through experimentation, please share it with us.