People interested in agile development gathered from all across the Northwest (Beaverton, Gresham, Hillsboro, King City) to attend AgilePalooza Portland last month.

The attendees were eager to get started. An exceptional collection of agile development experts were poised to share knowledge, excite, inspire and persuade.

After sharing logistics and speaker introductions, it was time to get out of the way and let the learning begin.

Before the stage was yielded to the keynote speaker, Santeon Group’s Ahmed Sidky, I asked the Portland audience a question:

“How many in the audience had participated in an Open Space?”

The Portland Agile Community was eager to participate in Open Space.

A stark silence gripped the room as two lonely hands reached up.

With the Open Space comprising the entire afternoon schedule, I was concerned:

• Would the attendees all leave after lunch?
• Would a lack of familiarity hinder the effectiveness of the Open Space sessions?
• Would the morning session feedback be negatively impacted by the inexperienced ‘Open Spacers?’

The morning prepared speech portion of AgilePalooza Portland began to be delivered. Ahmed Sidky, Diana Larsen, Dave Sharrock, Michael Tardiff and Steve Ropa connected effectively with the eager minds who had taken time out of their busy lives to learn agile for the first time or to ‘sharpen the saw.’

As the attendees finished lunch, we put the finishing touches on the Open Space preparations and gave control of the event to Diana Larsen, the Open Space facilitator for AgilePalooza Portland.

While Diana Larsen briefed the group about Open Space, I glanced around the room and observed one thing:  a full house!! The inexperienced ‘Open Spacers’ were willing to give it a shot. And I am glad they did.

The topics were selected and the discussions spread freely and easily:

• Testing in agile
• Where do technical writers fit in the world of agile?
• ScrumMaster struggles

For the next two-and-a-half hours, project managers, developers, testers, development directors and product managers learned, pushed, pulled and debated the issues that mattered to them most.

A beginner ScrumMaster asked, “How do I get better engagement for the Scrum Team?”

An even more inexperienced ScrumMaster gave a suggestion that was insightful and gave the questioner just what she wanted…

Try the Temperature Reading game or ‘strongly encourage’ all Retrospective attendees to place a sticky note on the wall that cites ‘what went well?’ and one sticky note that cites ‘what can we do better?’

It was a great AgilePalooza Portland and a buzz-worthy Open Space. Thanks to the Portland community for embracing the event and expanding the collaborative power of Open Space.

Dan Naden
VersionOne

Get the takeaways of the week, once a week.  Everything you love, everything you missed, and all the stuff you need to see again… in agile news:

Controversy Over Story Points Reaches Fevered Pitch
No two agile teams use story points the exact same way and according to Mike Cohn many teams don’t really understand them either. Christopher Goldsbury followed up with Mike about his recent blog on story points to find out if some agile development teams are really that clueless.

Are You on the List? Probably NOT!
Get the scoop on the who’s who of agile development in Peter Saddington’s post on the history of agile. Flash back to 1992 with Alistair Cockburn through 2003 with Mary and Tom Poppendieck.

Pretty Pictures Can Turn Your Retrospectives into Rainbows and Unicorns
Retrospectives can often be contentious at best and worthless at worst but sometimes a sunny picture can actually make them productive. Diana Larsen introduces the concept of drawing a “Project Weather” picture in retrospectives to gauge the climate of the team. Good idea or too touchy feely for your team?

What else made this week the best week ever in agile? Let us know about interesting blogs, articles or other stuff going on in Agile/Lean/Scrum/Kaban.

This advice comes with a disclaimer… I am a warrior, so my message will be harsh.

Resistance to agile development is futile. I say this to show the ‘Trekkie’ in me and to set the framework for destroying resistance to agile.

Personal Resistance: When faced with, “I don’t see the value of agile,” I remind the troops that management has hired me, the ScrumMaster/Coach, to help them transition to a different way of working. Whether the label for that change is agile, Kanban, whatever, my presence is a signal from management that something was wrong. The strongest resistor to change is my first and favorite target. I take them aside and challenge them respectfully and directly with, “Please don’t tell me that you are resistant to agile; please let me come with you to speak to the agile champion who sits three levels above your manager. I want to hear you tell him you will resist, or bring me a note from the agile champion, excusing you from changing your mind.” That is truly the last resistance I hear from that person. Resistors who turn into ‘Saboteurs’ or ‘Feet Draggers’ are eventually rooted out by the team.

Political Resistance: I gather managers in a room and I ask the following question:  “Who is onboard with this transition to agile, RAISE YOUR HAND?”  I then instruct every manager to look around and see who has not raised their hand. I then say, “I’m going to leave the room now and let you handle this amongst yourselves… I will call this meeting again and I expect every hand to go up next time.” Once the resistance is out in the open, it’s easier to deal with.  I do not interrupt the managers as they deal with each other on a peer-to-peer level.

Cultural Resistance: I gather any managers, team leads and executives I can and expose them to the Schneider Model — Command & Control, Competence, Collaboration and Cultivation. I ask them questions based on the readings right out of the book (Use the Appendix for Strengths and Weaknesses of each culture to create your list) and tell them, “We are marching toward Collaboration, with a dash of Competence.” By forcing executives and managers to discuss, debate and fight about who they are now and what they want to be in the future, is the exact conversation that must take place before ANY transition to ANY process, has ANY chance of taking root or being successful.

As a ScrumMaster, I use persuasion, influence, wisdom, experience, empathy and sympathy to lead and grow my teams. But sometimes I must tap into the strengths of being a New Yorker who was raised by a strict code of ethics, topped off with a dash of service in the military.

Please remember this one thing:  If you speak the truth and you do it with respect, you should be allowed to say anything to anyone.

Questions? I’d like to hear from you at msegarra3@msn.com.

Manny

Guest blogger, Manny Segarra is a ScrumMaster at Intel Corporation in the Greater Denver area. As a Lean/agile coach and developer, Manny is dedicated to the development of teams, individuals and organizations. He is disciplined and compassionate in leading, learning and coaching, and has experience with TDD, paired programming, OO design and continuous integration. Manny’s 10+ years of experience as a developer, tester, UI designer, analyst, trainer and technical support has given him multi-faceted perspectives on the user experience of software.

Get the takeaways of the week, once a week.  Everything you love, everything you missed, and all the stuff you need to see again… in agile news:

• VersionOne and LeanKit Kanban Announce Availability of Long Awaited Integration [Insert shameless plug here]. Get the full story.
• Alan Shalloway Quotes Einstein and Stirs Up Controversy. Alan shared his thoughts on the differences in mindsets between  1st generation agile (old school) and 2nd generation agile (new school). Read Mindsets: Waterfall, 1st & 2nd Generation Agile – check out the comments section for the juicy stuff.
• You Don’t Need No Stinkin’ Filters! Esther Derby might be talking to you, but are you listening? Esther tells a frightening tail of Ted and how his lack of self-awareness caused big problems with his team in her blog post Self-Awareness Matters: Finding Your Filters.
• Old Agile Blog Posts Rise from the Dead… and are still relevant! Scrum still fails, and works sometimes– How to Make Scrum Fail.  Agile teams still can’t self organize – Succeeding with Agile: Leading a Self-Organizing Team.

What else made this week the best week ever in agile? Let us know about interesting blogs, articles or other stuff going on in Agile/Lean/Scrum/Kanban.

The team had been locked in a room for 8 hours with long-time respected teammate, Fred, who now had a horrifying funk emanating from his body that made nose hairs curl. How did I handle the situation?

Dutifully and reluctantly, I called Fred into a meeting room and explained that there had been anonymous complaints from the team about how his smell was offensive and distracting to the rest of the team.  Naturally, Fred was a little taken aback.  Here he was just 30 minutes ago, joking around and working with his team and friends, and now he was hearing how these same people were ready to kick him to the curb because they thought that he didn’t know what a shower and a bar of soap looked like.  Fred acknowledged that there was truth in the matter of the odor, but not for the reasons that everyone else thought.  Contrary to popular opinion, Fred had not forgotten how to shower.  His team — people with whom he had been friends for years — so quickly assumed that was the only logical answer, and this fact hurt him deeply.  Why hadn’t anyone from the team brought this up to him directly?  Why didn’t anyone think to ask if everything was OK, rather than assume the worst?  As Fred explained, he had recently developed an infection in his left foot and try as he might, it just wasn’t healing.  While he freely acknowledged that he shouldn’t have let the situation go unchecked for as long as he did, he was deeply troubled by how quickly his team had turned on him, and how two-faced his supposed friends now seemed to be.

Shortly afterward, Fred did consult a medical professional for his foot, and as a result was diagnosed with Advanced Type 2 Diabetes.  And while Fred had to have his foot amputated to just below the knee, he was fortunate that the consequences were not worse.  After a few months of recovery and rehabilitation Fred was back on his feet foot.  He did eventually return back to work, but his relationship with his former friends was never the same.  He was as cordial, polite and hard working as ever, but it was clear that a new dynamic had emerged.  The people he had once considered his trusted friends were now only co-workers and teammates.

While I don’t regret having this conversation with Fred (I believe it forced him into seeking help probably a little sooner than he would have otherwise), I do regret how I had the conversation.  As a leader of a team it’s not my job to bring order and harmony to the team, but rather to help the team bring order and harmony to the team.  I should have never allowed the team to lodge what was essentially an anonymous complaint about one of their own, especially when that complaint was so out of character.  Instead of immediately going into fix-it mode, I should have reminded the team that the situation they were describing was pretty out of character and encouraged them to discuss this directly with Fred, just as they would with any of their other friend.  If that would have still proven too uncomfortable, then I should have offered to facilitate the discussion with all the team members present.

No matter how you approach it, the discussion itself would have been uncomfortable, but it didn’t have to be alienating.  With just a slight change in approach, Fred’s dignity would have been preserved; the team would have learned an important lesson in self-management; and otherwise long-term work friendships could have been preserved.

As leaders, our tendency is to treat conflict as just another impediment — something that needs to be dealt with post haste.  Although team conflict can be distracting and impeding, it’s far too complicated to be simply managed away like other impediments.  Conflict can be a rich source of inspiration and a valuable learning lesson for a team.  Managing team conflict almost always challenges and involves people’s beliefs, personalities and feelings.  It’s hard for people to grow without healthy retrospection on who we are, how we tick and how we work with others.

So next time, before you try donning your cape and rushing to the rescue to put out the next team conflict fire, remember Fred’s foot and say no to anonymous complaints.  Insist that the whole team be part of solution.

Many years ago, I had my first opportunity of leading a team of folks.  I was young, ambitious and eager to prove that I was the right person for the job.  Naturally, when the team came to me with issues and impediments, I did all I could do to fix things as quickly and painlessly as possible.  As I saw it, my job was to bring order and harmony to the team.  The happier they were and the more focused they were, the better we all were.  While I still believe that a leader is there primarily to serve his/her team, maturity and experience has changed my thoughts on what this really means, especially when it comes to dealing with conflict in the team.

I, like most people, spend more time than I’d care to admit, replaying past encounters and exchanges in my head.  If only I’d handled X, Y or Z differently…  If only I had said this instead of that…  Rationally, I understand that in the grand scheme of things, most decisions of the past wouldn’t have resulted in any material differences today, and the only one lamenting these old decisions is me.  That said, like Ebenezer Scrooge, there are some ghosts from the past which I can’t help avoid.  This is the story of one of those ghosts, and the lesson it taught me regarding dealing with conflict in the team.

Fred (name has been changed to protect the innocent) was about the nicest guy you could imagine.  He was an older gentleman, and had been with the company for quite a long time.  His work ethic was unquestioned, and he had the respect and admiration from his peers as being someone who knew his job well.  Fred was a regular at team happy hours, and he was always willing to help out fellow team members, even outside the hours of 9-5.  To say that Fred was an ideal team member and teammate would be an understatement.  Of course, this is what made matters more troubling when signs of unrest and discord started to rear their ugly head.

As we are apt to do when deadlines are pressing and work is time-sensitive, Fred and the rest of team were removed from their normal workspaces and sequestered into a shared team room.  Change always creates new stresses, and for this team putting them together in a conference room for 8 hours a day did exactly that.  People were a little more snarky and tempers were shorter, but it didn’t seem like anything they weren’t going to be able to handle until midway into the second week when one of the more outspoken team members came forward as “spokesperson” to tell me that the team was ready to stage a coup.  In a time before reality TV and “Survivor” were a part of the pop culture vernacular, they were all ready to vote Fred off the island.

It seemed that since Day One of the team room arrangement, they had all been suffering through horrible odors emanating from Fred, although they never let him on to that fact.  They had tried to be patient, assuming that even he would notice the smell and be forced to bathe, but they were wrong.  The odor had grown so foul and distracting that they vowed to abandon Fred alone in the room unless something was done and soon.

Upon hearing all of this, my first thought was that I needed to fix the problem ASAP.  Hygiene is a personal problem, and I couldn’t naturally expect the team to tell one of their peers that he had better start bathing, or else.  No; this was a job for the manager.  This was a job for me.

Check back on May 2 for a surprise “twist” in Part 2 of this series.  How did I handle the situation?  Retrospectively, how could things have gone better?  And what happens when you aren’t managing team conflict effectively?

The leading barrier to further agile adoption – as noted in VersionOne’s 2011 State of Agile Development Survey – is the ability to change organizational culture. Unfortunately, agile development teams can’t fix this problem by themselves because changing an organization’s culture is a leadership challenge. And companies have to want it.

Some organizational cultures are more difficult to change than others. An even greater challenge is that some companies are delusional, making statements about their culture in slide decks or other pronouncements but living a very different reality. Mike Rother made the following observation in his book, Toyota Kata : Managing People for Improvement, Adaptiveness and Superior Results:

“The unspoken business philosophy at some companies is simply to produce and sell more. Or it is about exercising rank and privilege, and thus avoiding mistakes, hiding problems and getting promoted, which become more important than performance, achievement and continuous improvement.”

The reality is that companies today face serious challenges with surviving in this globally competitive, turbulent business climate, and leaders need to recognize that their old model of work is outdated – and why – along with what they need to evolve into. And we’re only just beginning to communicate what that means.

Organizational agility is a huge shift that involves a range of interlocking pieces: leadership agility, autonomous teams and business units, HR practices, IT, budgeting, etc.  It’s going to take some very hard work over a long period of time for companies to learn what it means to be agile in a broader context. In their book Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap, Jeremy Hope and Robin Fraser clearly articulate this challenge:

“…the management model used by most organizations today is not up to the job. It was designed to enable leaders to plan and control their organizations from the center. Enabling business units and subunits throughout the organization to focus on creating value for customers and shareholders was never part of its design.”

In many ways, agile is an antibody which the existing system will attempt to eradicate, or at least reduce to a mild inconvenience (sniffle). This is why agile teams need to be protected and isolated from the rest of the organization; there will be constant pressure to conform and comply with established patterns of work. We want to advance to a new model, not be pulled back to the old one!

There is an opportunity for agile development teams to become part of the organization’s learning process. Demonstrate that agility works and become a working model, not only on what to do differently, but why. It takes a continual stream of messaging over a period of time for organizations to learn new things and apply that learning in order for it to stick.

I’m deeply passionate about and firmly convinced of the transformational benefits of agility – organizational agility as well as agile development – that I’m willing to continually champion all things agile at every opportunity.  What can we do – or should we being doing – to promote agile more effectively and change how businesses operate?

A common occurrence when driving the change to agile development is that once you start to try to increase the circle of influence of the initiative, you will undoubtedly run the risk of encountering cultural, personal and political resistance to the change.  There are certainly a number of team-level and top-down stakeholder-level approaches which agile coaches and agile champions can pull from their tool belts; they select the appropriate ones based on the context and their circle of influence/control.  The one universal tool for agilists and Lean folks that is often not leveraged adequately, and the one I want to talk about in this post, is the fundamental concept of ‘make agile visible.’

For example, let’s say we have a scenario where teams in one group are working in an agile development fashion and producing deliverables that then need to be assembled and deployed as a release by a second group working in a more sequential manner. This second group delays the release of value and causes significant work inventories to stack up in the overall value flow.  A third factor is that this group is also testing the release package(s) for deployment (late-stage integration) and sending defects back to the teams who originally created the features of the release long after they were considered done. This adds risk to quality, and more variability to the agile development team’s work queue.

One of the fundamental ways to shine a light on this issue objectively is to measure and make visible the metrics to show the cost of delay by such a release scenario.
With these metrics you are much better equipped to have conversations with stakeholders. Having a value flow that shows where the bottlenecks are is one way.  A team with whom I have worked has two tiers of Kanban boards, which serve as an excellent means for identifying the unnecessary cost and risk being added to the system. The top tier is for the
release-level picture and the second level(s) are for the teams involved in building, testing and releasing the product.

In the scenario I described, you would see a significant inventory of demand for service stacking up in front of the release operation group.  This adds inherent risk to throughput, quality and business agility.  Depending on the product/service domain, some teams will decouple the cadence of building the product from releasing the product. This tactic would clearly shine the light on the bottleneck of a more waterfall process-oriented release group and how they are preventing the accelerated delivery of value to customers and users while impeding agility.

Lastly, ensure you truly understand the perception of the ops folks if you find yourself experiencing a similar scenario.  Most resistance to change is driven by fear, which is usually rooted in not knowing the benefits to the individual (not just the benefits to the company).  This can be remedied by education and possibly a pilot.  Second, the management over the ops group may have a reward system that motivates behaviors and work patterns more consistent with serial execution.  Find out what metrics they are using to drive the reward system, and whether they’re counter to a team-based, outcome oriented reward system.  If the reward system is contrary to agile team execution, this may be another front upon which you might need to influence change by making the dysfunctional reward model visible.

In my first post we learned that traditional project management brings with it challenges in achieving software success – for both the software delivery team and the customers. When you ask for all the expectations up front and then don’t leave room for customers’ needs to evolve, it’s tough for results to meet expectations. Agile software, on the flip-side, leverages 4 basic concepts to ensure project SUCCESS. These are:

1. Product Owner Engagement. The customer (a.k.a. Product Owner) stays engaged with the team delivering throughout the project lifecycle. In fact, the PO is part of the team. At no point in the process should the PO disengage; decisions and expectations are set near the time the need is built, and subsequently delivered. Requirements evolve. And since the PO stays engaged, changes should not be surprises to either the delivery team or the customer.

2. Quick, High-Value Wins. Needs are delivered in small, manageable and valuable bites. This means the delivery team and customer work together to understand what is the smallest piece of value that should be delivered first, and they deliver just that. This approach helps both the customer and delivery team by narrowing focus, resulting in faster delivery and a focus on getting the high-value need right (with quality). By the way, if the delivery team falls short of expectations for some reason, it should not be a surprise to anyone and since we handle just a small bite. We fail small.

3. The Checkpoint Demo. At regular intervals, the delivery team (including the PO) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum, enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demo provides a checkpoint for measuring success, as well as a way to continuously mold and refine expectations.

4. Continuous Feedback. Conversations are constant within the delivery team, with the customer and with stakeholders. Instead of having formal meetings that are dubbed “Status Meetings,” we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, he or she grabs key team members and the PO to discuss real-time. This results in a clear understanding and lack of “hand-off breakdowns,” where information is translated as it passes from one person to another.

There are many more things we do with agile software delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best practices and a ephemeral drive to get better). But if you start with the above ideas, I can assure you that the software delivery team and the customers will start getting that feeling of SUCCESS.

What are your thoughts?  How does your software delivery team measure success? Another great question: Do you define software SUCCESS before you start your projects?

The people have spoken:

“Open Space: Alan Shalloway helped lead discussion. Loved it!!”

“Great discussion and interesting topics.  I will definitely be back.”

“Loved having an open dialogue with people from different companies/experiences talking about the most popular topics — the challenges and what has worked.”

For the past 3 years, VersionOne has been hosting AgilePalooza community events around the nation. AgilePaloozas attract directors of development, project managers, developers, engineers, CIOs and CTOs to join together for a day of learning about agile project management.

Come learn, share, grow at AgilePalooza.

The jam-packed day features internationally recognized speakers such as Esther Derby, Dave Hussman, Diana Larsen and Sanjiv Augustine sharing their unique insights on scaling agile, teamwork, collaboration, effective estimation and much more. The momentum doesn’t slow in the afternoon with an engaging, collaborative, flexible open space session. This session gives all attendees the opportunity to connect with peers and experts and find the answers to the specific problems that his/her organization faces.

Not convinced?

Here are the top 4 reasons you should stop everything and sign up for the next AgilePalooza, coming to a city near you:

1. Value:
You won’t find a better ROI in the industry. Seven hours of learning from experts and sharing best practices with like-minded peers is a can’t-miss opportunity. Setting up a similar event at your company would cost thousands of dollars in consulting, operational, travel and event fees.

2. Content:
Where else can Alan Shalloway, Lean Startup extraordinaire, tell us how teams and organizations can deliver value to customers in the morning and then have Diana Larsen, collaboration expert, take an active role in the afternoon’s open space discussions? You’ll learn so much, your fingers will be tired from typing or taking notes.

3. Interactions:
Change is hard. Change is even harder when you ‘go it alone.’ AgilePalooza attracts the best and brightest developers, testers, project managers, ScrumMasters, directors, VPs and CXOs from companies just like yours. When embarking on a change such as agile, you’ll take solace in knowing that others are on the same path, and you’ll learn plenty by hearing how they overcame the challenges that you face daily. Once you go open space, you’ll never go back.

4. Growth:
Tomorrow’s opportunity requires that you know the basics of agile – period. As more Fortune 500 companies choose agile for their software development projects, it’s imperative to be able to walk the walk AND talk the talk. When you sign up for AgilePalooza, you position yourself more effectively versus your peers.

And to thank you for reading this far, I’d like to share a promo code to get 50% off your registration for the April 13th, 2012 AgilePalooza in Portland. Just visit AgilePalooza.com now and sign up, using “V1Save50-T” as the code. Or check out our schedule of Paloozas to plan your next event, coming to a city near you. We look forward to meeting you.

Dan Naden
Senior Community Marketing Manager
VersionOne

When I talk with people learning about agile software, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then breaks up into groups and – based on their experiences – comes up with a list of critical elements they’ve noticed on successful projects. This exercise is meant to bring people to the concept of what makes up the Agile Manifesto.

The interesting thing is that in many cases, we discover that we’re programmed to believe that project failures relate to not knowing everything up front. I almost always hear, “complete, thorough and approved requirements” as elements of a successful project. This programming aligns well with the formula of success, which I learned during my short stint at an ERP consultancy firm:

SUCCESS = RESULTS – EXPECTATIONS

This formula leads us make sure that we set clear expectations so that we can meet and hopefully exceed them – thus, leading to success. However, as we know and learn in agile software delivery (and really in any process), thinking that the users/customers know everything about a project (a.k.a. need) 6-9 months before they get their hands on it is simply a fallacy.

Sure, we can make the customers agree to the expectations ahead of time. But doesn’t that negate the ability to achieve value and ROI for the project? What generally happens is that the users/customers define the requirements and agree to them; then sometime about a month before the project is delivered, they get their hands on some working capabilities and then say things like:

• “This doesn’t work like I expected; can you add a screen that does this?”
• “We’ll need a report that gets generated daily.”
• “If we don’t get these, we really can’t use this product.”

The response of the software delivery team is usually something like, “But you signed the requirements document” or “Those are great ideas; we’ll need to do that in the next phase” or “That will need to go through the change control process; we’ll need to escalate this.” Ultimately, the team isn’t happy because they don’t get to experience SUCCESS. The RESULTS fall short of EXPECTATIONS. On top of this, the customer isn’t happy either.

In an agile software approach, we can improve our SUCCESS rate by applying 4 very basic ideas. On Friday I will follow up with these 4 ideas and provide some tips on how you can give both your software delivery team and your customers a feeling of SUCCESS that is difficult to achieve in traditional project management.

There can be many reasons organizations struggle with their agile adoptions, but often it is because they’re clinging to the idea that only a select few people can be trusted to do the real thinking.  Design decisions are left in the hands of the leads or senior engineers, and so are the estimates. Tasks are then doled out as piecework to the “team resources” (who were recently drafted from the resource pool). Problems that arise are funneled to a leader, who evaluates them and dictates a plan of action.

This type of “savant leadership” — or a few smart people taking it upon themselves to be the brains of the operation — tends to perpetuate a learned helplessness among the team members and a lack of a sense of ownership of their work. This has the unfortunate side effect of increasing the possibility that the work won’t get done on time and/or won’t be acceptable. And since all the decision-making is done by somebody else, who can blame the team when things take too long or it turns out that they built the wrong thing?

Moreover, if the same handful of people always have the floor, existing blind spots become even larger. The ensuing groupthink can be suffocating to opportunities for innovation, both in terms of product and process.

So although we might have applied agile development labels and we go through the formalities of the prescribed meetings of some particular agile development framework, if we haven’t changed the way we think about our work and the people with whom we work, we’re not going to see better results than we did before. We’ll just have bundled the same set of ineffective principles and practices into some new packaging.

The frustration most of us dealt with for years in waterfall is that we tried to plan and control our way to success, but we found that the world around us wasn’t particularly interested in complying with our plans, and always seemed to wiggle free of our controls. What’s refreshing when we first stumble upon this agile stuff is that we’re allowed to acknowledge (finally!) that we’re dealing with adaptive problems — problems for which there is no canned solution, and which may morph as we begin to apply solutions. For an organization to be successful in dealing with such problems, its leadership must be correspondingly adaptive. In doing so, adaptive leadership shouldn’t attempt to provide all the answers, but rather, make a practice of keeping the vision clear and becoming really good at framing the right questions so that their people can collaboratively devise the best solutions possible right now.

Two very common objections to this concept are:

• “Only our senior people really have the system knowledge to make design decisions and estimates”
• “Our system is too complex”

To the first objection, I have to ask why that situation is acceptable. The adaptive leader would recognize this as risky on more than one level, and ask, “What can we do to ensure system knowledge is disseminated throughout the team(s)?”

To the second objection I’d say, “Maybe it is… So what are we going to do about it?” Since we know that man-made systems (especially software systems) are likely to become more complex than they are less complex over time; complexity in the system is going to grow unless something is consciously done about it. So instead of being fatalistic about it, and allowing this to be used as a reason to throttle collaboration, the adaptive leader would recognize this objection as a warning of even more limitations to come, and begin looking to the organization’s team(s) for a way to understand and reduce the complexity.

High-performing organizations have long realized the advantages that can be gained through the collective creativity and intelligence of empowered (pronounced “trusted”) people. Start trusting your agile development team. Give them a license to think, listen to them, let them devise solutions to the problems they face, and reap the rewards.