Think Less and Deliver Better Software

Simpler Is Better

Why is it that many of us strive to make things more complicated? Maybe it’s human nature or maybe it’s simply because we can. Regardless, complexity is often unnecessary and it can be just plain evil at times.

As the software systems we build grow more complex, the development approaches we use to build them become correspondingly more cumbersome. This is a matter of necessity. Complex systems have more of everything.

• More Features,
• More Menus,
• More Options,
• More Rules,
• More Controls,
• More Security,
• More Parameters,
• More Bulk!

Do we really need more, more and more? If you want to build better software, faster and more predictably, think less — plan less, build less, test less, deliver less, do less. How?

1. Keep the core software feature set minimalist. Only add new features that offer high value based on the opinions of the Product Owner and Executive Sponsor.
2. Open up the design so that software tools and utilities can be added to the software. These add-ons, applets, plug-ins, packages or whatever you choose to call them can be built and released independently of the core product. [Separate agile development teams can work at their own paces.]
3. Offer multiple ways to use the data that feeds the software. Other applications should be able to read the data and — with some controls — be able to write new data. [Reporting is the obvious use for this but it can go far beyond that.]
4. Let the user community customize the look, feel and operation of the software in as many ways as you can. They will be happier and they’ll make fewer demands of the development team.

Leaving out features, menus and options can be a good thing. It forces people to think for themselves. It frees them to be creative. One of the reasons business users ask software developers for so much is simply because they are at our mercy. They have no alternatives.

Stop thinking about the way things used to be. Today’s user community is much more technology savvy than yesterday’s. Twenty years ago — even ten years ago — we had to spoon feed business users. They were new to computers and software. They had to learn and adapt. Not any longer. They get it.

Turn them loose. Give them tools and let them customize the software to their liking. You’ll find that new ideas emerge and the software becomes better than anyone expected.

While you’re at it, stop adding new rules — you can’t do this — you must do that. Enough already! Keep the rules to a minimum so people actually understand them. Hold everyone accountable for following a few important rules. Monitor what people really do using log files and internal social networking features.

Simpler is better. Think less, not more.

photo credit: Yoshi Shih-Chieh Huang via photopin cc

Sprint Zero – Your Context May Vary

I’ve advocated for using “Sprint Zero” a few times on this blog and each time I get some negative feedback. I’m going to continue my crusade in this post but with a twist.

Firstly, recognize that “Sprint Zero” is about ‘hitting the ground running’. That is, getting the team ready to start writing code that implements user stories. That’s it. Sprint Zero is not about doing extended analysis and design. It’s not about writing specifications either.

If you believe your team has enough information and knowledge to start writing code, go for it. Sprint Zero is not mandatory though it helps in the right contexts. I’ve also written about context before. Often, when I see people disagree, they are envisioning different contexts. Thus they are both correct within their contexts — and they are both wrong within the context of the other person.

Example Contexts

There are an almost infinite variety of contexts when it comes to building software systems. I’d like to consider enterprise systems for these examples. I’m willing to agree that for small systems built by stand-alone teams, Sprint Zero is often unnecessary, though it may be beneficial.

Consider these situations:

1. Replacing an existing system with a completely new implementation.
2. Upgrading an existing system using the existing infrastructure and tools.
3. Creating a new system that provides functionality not currently available.

Now let’s consider the knowledge base of the team:

There are four possible scenarios in my simple example. They revolve around the type of software system being built (e.g. CRM, payroll, order tracking, etc.), the tools and technologies being used, and the current software system (if one exists).

Here’s what it looks like in tabular form. ‘Yes‘ indicates the team has experience with the column heading. ‘No‘ indicates they don’t.

Situation 1: The team has plenty of experience. Sprint Zero is not needed unless the business wants something radically different.

Situation 2: The team lacks experience with the current system. Sprint Zero provides an opportunity to assess the features and performance of the current system as the team prepares to make changes. Gathering metrics about the current implementation will be helpful in assuring that system performance doesn’t degrade during the project.

Situation 3: The team has functional experience but lacks the technical skills required by the system. Sprint Zero offers an opportunity to learn how the current was built and how it operates.

Situation 4: The opposite of Situation 3 — technical skills are available but functional experience is lacking. Sprint Zero may not be needed unless the system is highly complex.

Situation 5: The opposite of Situation 2 — functional knowledge is available but technical skills are not. Training will help and should be done before the project begins. Sprint Zero may help in understanding how the current system was built as in Situation 3.

Situation 6: This is the worst case — usually a junior team thrown together to fix or build something. Sprint Zero is strongly recommended!

I’m only scratching the surface of the many contexts — types of situations and scenarios — that occur but you should get the idea. Sprint Zero is not always necessary and it’s goals will vary.

Finally, if the team feels uncomfortable about the project, use Sprint Zero to define stories that will address the team’s concerns and define a path forward. For example, if the team is unsure about the system architecture and design, what can the team do to decide on an approach? Create a task list and turn it into Sprint One.

Some will accuse me of violating agile principles by suggesting that the team work on something other than user stories. Get over it! The goal is to deliver working software to the business. You need to do whatever it takes to get there — and you need to do it sooner rather than later.

photo credit: Megathon Charlie via photopin cc

Enterprise Projects Need to Start with Sprint Zero

The idea behind “Sprint 0″ is that software development teams should spend some time at the beginning of an agile project doing analysis, design and other preparation tasks. I’m not referring to small projects — a few people for a few months. I’m thinking about enterprise projects involving multiple teams deploying to multiple servers.

At the lowest level, good software is good software. The tools and techniques used are analogous regardless of the size of the resulting system. At the highest level, good design at a small scale does not translate into good design at an enterprise scale. New problems appear at scale. Those problems demand new ideas and unique solutions.

Sprint Zero Gets a Bad Rap

I think many people despise the idea of “Sprint 0″ because they envision a bunch of managers and technical hotshots hanging around trying to manage every last detail of the project. They also interpret the Agile Manifesto too literally in assuming that only delivered software has any value — everything else is fluff.

If it was possible to dive in and create an elegant enterprise system design by simply writing code, I’d be all for it. Why do extra work? Let the code drive the design.

That may work for small systems but in enterprise systems, it flops. The resulting code always requires rework — often to the point of being discarded and re-written. That leads to the second Manifesto misinterpretation. Redesigning code does not qualify as ‘refactoring‘. Look it up. Refactoring changes the internal structure of code not the external behavior.

If the design doesn’t scale, refactoring won’t help. If you have to start over after one or two sprints, skipping Sprint 0 was a bad idea.

The Challenge

We need to do some analysis and design at the outset of big projects without getting sucked into creating gantt charts, requirements specifications and technical design documents. Here are some questions to answer during sprint 0.

Implementation Questions

• What is the scope of the project (vision)? What are the key goals?
• Who will be involved in the project? Do we have a sponsor, stakeholders, user representatives and key members of the software build team?
• How many simultaneous users will the software system have to support?
• How much data will be processed each hour, day, week, etc.?
• How secure does the system need to be (authentication, encryption, etc.)?
• How fast does the system need to respond?
• When will test data be available? (Not just contrived data elements but real world information that can be processed by the new software.)
• What software and hardware tools will we use? Are they already in house or must they be procured?
• What are the greatest risks we face? What can we do to mitigate them?
• What constraints exist and what assumptions are we making? (This would be a good time to write some exploratory code to test assumptions or evaluate risks.)
• What system interfaces are we dependent upon? Are they internal or external? Do they exist yet? (Another area where exploratory code may be helpful. If an interface does not yet exist, you may need to emulate it.)
• What will the user interface (UX) be like? (This is a good time to sketch up some ideas.)

Process Questions

• How will we work? How long will sprints be? What is the definition of done?
• Do we have a product backlog? Is there a separate backlog for this release?
• When do we have to deliver something (minimal release, full release)? Are there critical dates we have to hit?
• How will we know when we’re done? What are the key measures (budget, target date, minimum feature set, etc.)?
• What metrics will we track and how?
• Is the software development environment available? If not, what needs to be done?
• Is work space available? Will all team members be together? How will everyone stay connected?

If the stars are in alignment for your project, you may be able to fly through these questions in a couple of days and begin writing code. It’s more likely, however, that many answers will be vague or missing. Apply lean principles. Think about the simplest way to answer the questions.

You may decide to put off answering some of these questions until a few sprints are done. That’s okay. Having gone through this exercise, at least you’ll know what’s ahead.

photo credit: gatogrunge via photopin cc

Don’t Ask Me What I Want, Give Me What I Need

I don’t know about you, but scenarios like the following happen to me all too often. I meet with the business stakeholders and representatives of the user community to discuss changes to a software application. We discuss new features and/or changes to existing ones. They give me a general idea of what they want. I describe how this might operate within the software. They indicate agreement and I go forth to develop the features in our sandbox.

Depending on the type of changes and which software development groups need to be involved, I may create a formal specification, write up stories and/or throw together a mock-up. For small efforts, I may simply make the changes directly in the sandbox (Salesforce.com makes this really easy). I can always write some kind of documentation after we agree on the implementation approach.

So far so good, right? I show them the sandbox implementation. They offer a few minor suggestions and ask how soon the changes can be deployed in production.

We love it … But …

Here’s where it gets interesting, amusing or frustrating depending on your point of view. The changes are deployed and complaints arrive in my inbox — usually only a few but on occasion, it can be a blizzard! Why does that happen?

1. Sometimes the stakeholders and user representatives didn’t fully understand the problem expressed by the end users.

They should have dug deeper and I should have engaged at least some of the end users directly rather than having all the information filtered through their reps.

2. Sometimes the stakeholders and user representatives didn’t fully understand the solution I proposed.

They should have spent more time exercising the sandbox implementation and asking questions. I should have explained the solution better and more importantly, I should have clearly defined what the software would and would not do.

3. Sometimes the stakeholders and user representatives didn’t really know what they wanted. Their real intention was to try something, see the result, and make another set of changes to the software based on user feedback.

That’s fine too, though they should have stated up front that they wanted to conduct an experiment. This is a communication breakdown that stems from lack of trust.

4. Adding more people to the discussion by deploying the software always generates new ideas and opinions.

That’s a good thing — as long as everyone is reasonable. I always listen carefully to everyone’s concerns and opinions. Most people simply want to be heard and understood.

5. Some people simply enjoy complaining.

Sadly, there’s nothing we can do about this latter group. Let them complain and always ask them for their ideas.

These issues don’t crop up every time but often enough to be troubling. Everyone is busy trying to operate their area of the business. Everyone has too many demands on their time. These issues will never go away entirely.

Welcome to the world of software application development. I don’t know what I want but I’m sure you can figure it out.

photo credit: Sybren A. Stüvel via photopin cc

Bulky, Legacy Programming Tools Cost Us More Than Money

Building great software has become too complex. I write many posts about the software development process and how to improve it but there’s an underlying problem. The art of writing software has become overly complex. That very complexity necessitates an overly complex approach to building it. It’s a vicious cycle.

It’s time to get back to basics. There are several software development environments that need to go. Having a diversity of software languages like C, C++, Fortran, Javascript, Pascal, PHP, Ruby, etc. is fine. Being forced to run a bloated operating environment to support the language is not.

We already run an operating system — usually Linux, OS X or Windows. We run a browser that is an operating environment in itself — such as Chrome, Firefox, Internet Explorer or Opera. So now we have a software environment within an operating system. Then, some vendors want us to run yet another environment that supports the programming language. Enough!

Here’s a short list of bloatware languages that need to go.

Adobe Flash

Flash is old technology. It’s widely used to deliver animation. Advertisers are probably the biggest fan boys of Flash. They can produce banner ads that grab attention and even interact with users. Alas, Flash is big, slow and full of security holes. It’s no longer needed as HTML5 can now take over its functions. It’s time for Flash to go.

Oracle Desktop Java

Java was originally a product of Sun Microsystems. It’s widely used in application and web servers as a way to process user requests and return meaningful results. It makes sense on servers. But, why do we need it on desktops? It’s huge and full of security holes. Some developers like it because they can build the software in Java and run it on any desktop computer. They need to learn HTML5 and an associated web-based language like Javascript, PHP or Ruby. Desktop Java needs to go.

Microsoft .NET

From a user perspective, .NET is horrible. Have you ever looked at the number of .NET “updates” Microsoft ships each month? Every major .NET release has it’s own set of updates. We are forced to install multiple versions of .NET on our systems to support different applications because Microsoft has designed it poorly. .NET replaced Visual Basic which was (arguably) one the best software languages ever. .NET is not progress. Kill it!

Microsoft Silverlight

Silverlight is Microsoft’s answer to Flash. Just what we need, right? Flash in Microsoft clothing. Even worse, Silverlight sits within .NET. It couldn’t be any bulkier! Silverlight has not caught on and never will. That shipped has sailed.

It’s time to move on.

These big, bulky software environments cause our desktop and laptop computers to slow to a crawl. They demand large amounts of memory and fast processors. In turn, these items add unnecessary cost to our systems and expose us to needless security risks.

Fight back! Avoid desktop applications and websites built using these obsolete tools — the software likely won’t run on your smartphone or tablet anyway.

photo credit: h.koppdelaney via photopin cc

Great Agile Teams are Adaptive and Resilient

This is the sixth and final post in a series about building great software using agile techniques. The series began here.

Many people, managers and developers alike, view agile development approaches like Scrum and Kanban as just another way to write software. Once they decide to try an agile approach, they quickly realize how wrong they are. Agile development isn’t about writing software. We assume you already know how to do that. Agile development is about delivering software.

I’d like to expand upon and summarize my original premises as follows:

1. Enterprise software development is complex and requires many skills. [Note: This series is not about small utilities or mobile apps. It's about software systems built and used by large groups.]
2. The agile manifesto is the definitive list of guiding principles and beliefs for agile development. [As such, it is a starting point, not an end game. We need more ideas.]
3. Agile development encompasses several approaches including Scrum, Kanban, Lean, XP, DSDM, FDD, BDD and others. [All are valid and applicable in appropriate situations.]
4. Applying agile development principles on an enterprise scale is much tougher than it looks. [Note: The Scrum of Scrums idea is merely a bandage.]
5. The hallmarks of truly agile teams are simple — they are adaptive and resilient.

What does it mean to be adaptive and resilient?

One of the key differentiators for agile developers is change. I’m not referring to accommodating user requests for changes to the software. That’s easy. I’m referring to changing the way the developers work. Changing the development process. Changing the very rules followed by the team.

Such changes need to be discussed, arbitrated and applied frequently — such as at the end of every sprint or cycle. If you’re looking for the ultimate, tried-and-true way to build software, look somewhere else. Agile development is about adapting to the current business situation.

If you develop software in a business that is changing rapidly or in an industry that is highly competitive, change will come at you fast. Your team must be able to learn and adapt continually. “Evolve or perish” is a good motto to adopt.

If your team is adaptive, there’s a good chance you can also be resilient. The terms are related though resiliency goes deeper. Resilient teams bounce back. They recover from adversity and find a way to succeed.

If you’ve worked on enterprise-scale software systems, you know that things will go wrong along the way — some things will go very wrong and cause near panic on the team. Resilient teams will swarm. They’ll apply their collective skills. They’ll change the rules. They’ll find a way to move forward.

The Attributes

To become adaptive and resilient, several attributes are essential:

• The team must be highly cohesive, loosely coupled and decentralized. [See this post.]
• They must implement constant feedback cycles and continuous improvement. [See this post.]
• They must exhibit rapid responsiveness and swarming behavior. [See this post.]
• They must have diverse skill sets and share a common vision. [See this post.]

Does your software development team have these attributes?

Would you describe your team as adaptive and resilient?

If not, what’s missing and what are you going to do about it?

I hope you found this series of posts interesting and thought-provoking. Whether you agree or not, I encourage you to leave a comment and expand the conversation.

photo credit: Seiya235 via photopin cc

Diverse Skills Need To Be Combined With a Common Vision

Great agile teams have diverse skill sets and share a common vision.

This is the fifth in a series of posts about building great software using agile techniques. The series started here.

If you read any books on agile software development, you’ll see references to multidisciplinary teams. That means the development team is largely self-contained. The developers have the ability to get the job done without excessive reliance on outsiders. Why is that important?

Enterprise organizations like specialization. They create many workgroups that focus on narrow areas of expertise. If anyone wants to do something covered by one of those specialized areas, they are required to issue a request to the appropriate workgroup.

For example, enterprise IT departments have database administration (DBA) groups. They include people who have the knowledge and authority to create and modify database structures. If anyone wants to create a new database or make changes to the structure of an existing one, they must request assistance from the DBAs.

There’s a good reason for that. If the enterprise has multiple systems relying on a database, changes have to be reviewed and coordinated. Making a change for one team could cause another team’s software to crash. Centralized control makes sense, right?

Until, the concept is taken too far. What’s too far?

• Applying the rule to every database even if it’s used exclusively by one software system.
• Applying the rule to development and QA environments, even if those environments are isolated (e.g. sandboxed).
• Applying the rule to every database change, no matter how small.

[I don't mean to single out DBAs for criticism. I'm merely using them as an example to make a point.]

Now imagine that there are several such specialized groups that every software development team must use. Each time they need assistance, they have to issue a request, enter a queue, and wait for availability. Does that seem agile to you?

Being Multidisciplinary Demands Vision

Agile software development teams have to be multidisciplinary by definition. They need team members who have multiple skills so that delays and wait times can be reduced or eliminated. They need an enterprise organization that gives them the independence to do whatever the team needs during the course of the project. Only then can real agility be achieved.

Having independence and using it wisely require that teams have a common vision. The team members have to work together with a shared purpose and a unified commitment. In this way, they’ll develop trust that, in turn, fosters collaboration. So through a common vision, the team will develop the strength to be independent and work as a unit.

Swarming won’t work without a common vision (see my last post). Even simple tactics like pair programming, will devolve into pair arguing without the joint commitment and shared ownership that derive from a common vision,

I’ve never said that enterprise software development is simple. While it’s fairly easy to be good, it’s difficult to be great and impossible to be perfect.

Is your team multidisciplinary?

Does your team share a common vision?

How would you characterize your team — good or great?

I’ll wrap up this series of posts on what it takes to be a great software development team in my next blog entry.

[The next post in this series is here.]

photo credit: chrismar via photopin cc

Agile Teams Swarm to Greatness

They are known for rapid responsiveness and swarming behavior.

This is the fourth in a series of posts about building great software using agile techniques. The series started here.

I’ve said before, “Plan less, deliver more.”

Others have said, “Stop starting and start finishing.”

Sounds crazy, right? How can your team deliver more software by doing less planning? How can they finish without starting? People who champion agile software development must be nuts!

Okay, these claims use exaggeration to make a point. Agile developers don’t sacrifice planning as a way to write more software. Nor do they skip project initiation activities and simply throw software over the wall into production. Let’s get serious.

The key point is a simple one. Agile teams respond rapidly. They quickly go from planning to designing to coding to testing to finishing. Then, they do it again — and they keep doing it until the software meets the goals defined by the stakeholders.

Don’t lose the excitement.

I’ve witnessed several cases where business stakeholders were excited by the prospect of a new software application. They cooperated in a lengthy discovery phase where requirements were gathered and documented. They grudgingly reviewed and approved hundreds of pages of documentation. Finally, they were told that the software would be delivered in six, nine or twelve months.

In every case, the stakeholders were disappointed and lost interest. In some cases, they sought out alternatives because the delay was simply too long. Business can’t wait.

Agile teams know that delivering something of value, early and often, is a critical success factor. They are fully aware of the need to respond rapidly both to the initial request and to the ongoing feedback after each delivery. Stakeholders need to experience the software not simply read about it. Incomplete software is okay. Nonexistent software is not.

Great teams swarm.

One technique agile teams use to respond rapidly is swarming. This is simply the act of coming together to solve a problem or get something done quickly. Great teams don’t point fingers at others or engage in blamestorming. They pull together and do whatever it takes to finish the current activities.

Swarming focuses energy at a critical area or key activity so it gets done. Most often, teams swarm when there is a mission-critical problem such as system or customer down. That’s fine though great teams use swarming as a planned activity. They recognize that difficult issues will be encountered during sprints and everyone will have to jump in and assist.

When you reduce the time spent on initial planning and designing, you have to anticipate that unforeseen issues and impediments will surface during the project. You could simply toss them into the backlog and worry about them later but your backlog could grow endlessly. Instead, great teams swarm. They try to resolve the issue or remove the impediment now. If they can’t, fine, move it to the backlog but only as a last resort.

Does your team respond rapidly?

Do you see swarming behavior in your organization?

If you answered no, greatness will elude you. Your team may be good, but it will never be great.

Swarming is a natural, instinctive behavior. It’s been observed in single-cell organisms, insects, wild animals and humans. Take advantage of it.

[The next post in this series is here.]

photo credit: gydnew via photopin cc

Even Great Teams Need to Get Better

Constant feedback cycles are the key ingredient to continuous improvement.

This is the third in a series of posts about building great software using agile techniques. The series started here.

Perhaps the biggest mistake software development teams make when adopting an agile approach like Scrum or Kanban is assuming they can lay out the perfect process from the start. They want to implement a set of rules or best practices ( …cringe… ) and get started.

It’s only natural. If your current development process is failing, you get excited about trying a new approach. You want to get it right. You want to succeed. That’s great! Enthusiasm is a wonderful trait.

… but …

Agile approaches to software development are not prescriptive. They don’t come with rule books. There are guidelines and recommendations but few “…you must do this…” or “…you can’t do that…” statements. A major part of being agile is the ability to adapt over time. The approach you choose will be simple in principle and must be adapted to your situation — once you get going.

Start somewhere, anywhere. Do something, anything. Learn and adapt as you go. That’s agility.

Approaches like Scrum and Kanban appear to be inherently simple. They are easy to learn and can be implemented quickly. You’ll need to add complexity as you adapt your chosen approach to your situation. The key is to get started with a simple model, then learn and adapt rapidly and continuously.

Agile teams must define a feedback loop. (Yes, that’s a rule!) They have to record everything. I don’t mean writing formal documentation for every activity. I simply mean informally gathering information that the team can discuss and use to improve their efforts. These feedback discussions need to happen often — usually at the end of each sprint (though I wouldn’t wait more than a month between them even if they occur in mid-sprint).

The best method we have for achieving good feedback and continuous improvement is the retrospective meeting. This may be one of the most under-used aspects of agile development. It’s not easy have an open and frank discussion with your teammates about what happened — why was a defect missed or how did a requirement get dropped — but it’s the best way to prevent adverse events from happening again.

I won’t go into detail on how to conduct retrospectives as much has already been written about the topic. Essentially, you want to ask questions like:

• What is going well?
• What isn’t going so well?
• What should we continue doing?
• What should we do more of?
• What should we do less of?
• What should we start doing?
• What should we stop doing?
• What should we track and measure?
• What can we stop tracking and measuring?
• Who can help us do better?
• What skills are we missing on the team?

You get the idea. Keep it simple and impersonal. Always keep Norm Kerth’s Retrospective Prime Directive in mind.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Today’s enterprise businesses change faster than ever. Even if it was possible to derive the perfect development approach for your team, in six months — twelve at the most — it will break. Don’t wait for your process to break. Keep learning and adapting.

[The next post in this series is here.]

photo credit: fish2000 via photopin cc

To Build Great Software, You Need a Great Organization

This is the second in a series of posts about building great software. The series started here.

In my last post, I introduced the idea that great agile teams exhibit a set of attributes that clearly distinguish them from legacy teams using waterfall approaches. Their techniques are also quite different from software teams who claim to practice agile software development but don’t. Here are the attributes I listed in that post:

• They are highly cohesive, loosely coupled and decentralized.
• They implement constant feedback cycles and continuous improvement.
• They are known for rapid responsiveness and swarming behavior.
• They have diverse skill sets and share a common vision.

This post focuses on the first entry on the list — They are highly cohesive, loosely coupled and decentralized. What does that mean? Let’s break it apart.

Highly Cohesive

In simple terms, a cohesive team is one that is closely united. The team members stick together. Their activities are logically consistent and supportive of one another.

These characteristics can’t be fully developed during the course of a single software release cycle — for example, 3-4 months. It takes time for great teams to “gel”. It’s not easy. Some companies fail at agile software development simply because they expect too much, too soon. Invest in training and coaching, and give it time.

Loosely Coupled

Great software teams are able to split large chunks of work (often called “epics”) into smaller elements (“stories”) and deliver working software iteratively and incrementally. They don’t rely upon a single individual to fully define or implement a major system capability. Anyone can select a portion of the system and work on it.

This doesn’t mean that everyone on the team needs to know everything. Refer back to “highly cohesive”. Team members help each other and accomplish their tasks collaboratively.

Decentralized

This term is self-explanatory and one of the most difficult attributes for enterprise organizations to implement. Enterprise managers are measured by their ability to control and execute. There is usually an expectation that every decision the team made — everything the team did — was pre-approved by a manager. If the team succeeds, it’s because of the manager. If the team fails, the manager takes the heat. If you were a manager in that situation, how would you handle it?

Great managers lead. They do not control. Great managers do not make all the team decisions. They do not approve everything. They most certainly do not make everyone wait while they “think about” the situation.

Great organizations decentralize. That does not mean that software development teams are allowed to run wild and do whatever they want. No! Great organizations enable their managers to lead. They establish goals. They offer guidance. They monitor and measure. They remove impediments.

How does your software development team measure up?

Is your team highly cohesive in your opinion?

Is your team loosely coupled?

Is your organization decentralized?

If you answered “no” to any of these questions, implementing Scrum, Kanban or any agile approach will be difficult. You are likely to end up with some form of iterative (or incremental) waterfall. That’s not a bad thing but it’s neither agile nor adaptive.

I’ll continue this discussion in my next post. In the meantime, please join the conversation.

[The next post in this series is here.]

photo credit: Rebecca-Lee via photopin cc