Here’s a simple example. Let’s say we have a team following Scrum principles. They have a well-groomed and prioritized sprint backlog. Well into the sprint, one of the software developers finishes working on a story. There are more stories in the backlog and plenty of time left to work on them. What should the developer do?

He might simply access the sprint backlog and select the story at the top of the priority list. Makes sense, right? There’s nothing wrong with that approach, however, it doesn’t do anything to encourage teamwork and collaboration. It’s simply a lone developer doing his thing.

Leverage the Opportunity

What if he asked his teammates if any of them needed help? — Is anyone stuck? Is anyone falling behind? — Ideally, the Scrum Master should already know the answers. In fact, everyone on the team should know via the daily standup meetings. The general idea is to get stories through the development process as quickly as possible. Having lots of stories in progress is inefficient and wasteful. The Scrum Master needs to keep things moving.

Another possibility is to have the Scrum Master consider the developer’s strengths. For example, if this developer excels at writing efficient database queries and one of the in-progress stories demands this skill, maybe having the story handed-off to this developer will help the team best. You could also consider having the developer pair with the one implementing the (query) story to take advantage of a learning opportunity.

Swarm Problems

Similarly, great teams solve problems together whenever possible. They don’t dump problems on outsiders and wait for a fix. They don’t expect team members to solve problems in isolation. Instead, they openly discuss problems, impediments, bottlenecks, etc. and brainstorm ways of handling them. Again, the daily standups are the right place to raise awareness of issues. (Brainstorming needs to be done outside of the standups as you know.)

Managers and others in leadership roles often want to jump in and solve problems. That raises two concerns. 1) The team members grow increasingly dependent on such behavior and don’t learn good problem-solving skills. 2) Forcing a solution on the team may result in backlash and unintended consequences. Solutions need buy-in. The best way to get buy-in is to have the team solve its own problems.

Get the idea? Great teams don’t blindly follow procedures. They exercise good judgment and have a genuine interest in helping each other. This doesn’t just happen. Scrum Masters, Product Owners, and organizational managers need to encourage collaborative behaviors.

photo credit: arripay via photopin cc

The whole approach is absurd but everyone feels powerless. It’s accepted — at least in part — because everyone is busy. Business people have jobs to do. They don’t have time to help software developers do their jobs too.

Now your software development team wants to collaborate with the business team. You might want to try an agile approach like Scrum or maybe you simply want to try an iterative waterfall technique. How do you get the business folks engaged in the software development effort early and keep them engaged? Here are five ideas to consider. What you ultimately decide to do depends upon your company’s culture and the level of executive support the project receives.

• Face It: Find reasons for face-to-face conversations with the stakeholders and power users. Make them feel needed and involved. It builds trust and establishes accountability. If people are spread out across the country or around the globe, schedule phone calls to solicit feedback. (But please don’t schedule weekly status meetings. These conversations should be spontaneous.)
• Visualize It: Prominently display the team’s progress. No gantt charts, please! Simple graphics are best. Even a kanban-like wallboard showing the release backlog and a few status columns with a progression towards done can work. Something as simple as taking a photo of the wallboard each week and emailing it around can help improve information flow.
• Show It: Schedule working sessions to demonstrate the software and get feedback. Don’t worry about missing features and defects. It’s a work in progress. Show ‘em what you got and ask ‘em what they need. Schedule these sessions on an as-needed basis. Try to make them fun as well as informative.
• Use It: In some cultures, early software deployments are taboo. The software can only be deployed when management says it’s done. In such circumstances, setup a workstation (or several) where people can drop by and actually use the software. Consider holding “lunch and learn” events to get people to try out the new software.
• Score It: If you use traditional alpha/beta cycles during software projects, don’t just ask for opinions. Create a score card. Don’t just deploy the software and ask for open-ended feedback. Pass out detailed assessment forms and ask everyone to fill them out. You’ll get better and deeper feedback.

I hope that at least one or two of these ideas resonate with your enterprise environment. Try to be open and transparent. Seek inclusion and teamwork. When people feel needed, they are more likely to collaborate.

photo credit: billnwmsu via photopin cc

Why would a company change the way it builds software systems? Companies change their approach to software development once they conclude that what they’re doing is too big, too slow, or too costly. They want better, faster, cheaper results.

Why would a person decide to go on a diet? People decide to lose weight when they believe they are too big, too slow, or too costly (as in having to buy a new wardrobe). We’d all like to be healthier, fitter, and more appealing, right?

Consider the Challenges

Whether it’s a company writing software or a person losing weight, the challenges are similar. Many companies struggle with software projects that are usually late, over budget or unreliable. Making major improvements is difficult. Flawed processes don’t just heal themselves. It takes a lot of work.

As for the challenge of losing weight, it’s hard to do. It may be a few pounds or a hundred pounds. Regardless of the amount, you have to make some some basic lifestyle changes. Excess weight doesn’t just magically melt away as some marketing campaigns would like us to believe.

The basic steps to solving either problem are the same. The steps might look like the following (along with some examples):

• Establish goals
  • Company: reduce time to market by 20% or lower customer support costs by 30%
  • Person: lose 50 pounds, run a marathon, or fit into an existing wardrobe
• Evaluate approaches
  • Company: iterative waterfall, Scrum or XP
  • Person: Weight Watchers, Jenny Craig or South Beach Diet
• Prepare to follow the approach
  • Company: identify training materials and train employees
  • Person: study the diet and chat with others that have followed it
• Purchase necessary items
  • Company: buy equipment and software; setup office space
  • Person: buy cooking tools and food items
• Start the effort and track progress
  • Company: use charts and graphs to show progress
  • Person: track weight and strength/endurance

I could go on but you get the idea. The similarities are striking.

If you don’t have clear goals, you’ll either fail from lack of direction or you’ll accept whatever outcome you get and call it a day. Proper preparation is also critically important, as is tracking progress. It all has to come together to achieve a successful outcome.

Oh, I almost forgot! The most important aspect of any change endeavor is commitment. Some things will go wrong along the way. Mistakes will happen. The journey certainly won’t be smooth sailing. Those that succeed in any endeavor are those that defined clear goals at the outset and were committed to success from the beginning.

That’s hard to do as an individual and it’s even tougher as an enterprise organization.

photo credit: Rance Costa via photopin cc

Much of the material is centered on the role of business analysts in software development. I know some will argue that agile projects don’t need business analysts. I agree — on small projects. I disagree on enterprise-scale projects. Big, complex undertakings need high-level analysis and design and it has to be done in an agile way. Blueprint gets it.

Here are a few excerpts that got my attention:

From Chapter 1: Meeting the Business Analyst

“In many ways the role of a business analyst parallels that of an author writing a story or screenplay — either way, you could call it “The Voyages of the Enterprise.” Indeed, the business analyst must tell the story of the application that the business needs and do so in such a way that the business stakeholders can easily consume the story and confirm that it meets their needs, and that the technology stakeholders (that is, testers, architects, and developers) can read it and understand what they need to test, design, and develop. As with any good story, the business analyst must use appropriate language, add in clear illustrations, and provide good visual imagery.”

I love the story analogy. Business teams don’t want to read technical documentation. They don’t understand all the acronyms and they don’t care. Conversely, technical teams thrive on technical details. Someone has to bridge the gap.

From Chapter 2: Conquering the Challenges of Business Analysis

“The challenges business analysts face are even more formidable because their daily responsibilities are in continual flux and undergoing ceaseless transformations. Why? … end-users take advantage of only 45 percent of delivered features (according to the Standish Chaos Report), and rework consumes 40–50 percent of project budgets (Boehm and Basili). Issues that the project team could have addressed when defining requirements are key contributors to these unfortunate numbers. In fact, faulty requirements form the root cause for 75–85 percent of rework (Leffingwell).”

“Good requirements and agile (development) are absolutely compatible … These requirements are detailed for each iteration individually to a level consistent with other methods just before implementation.”

This approach mimics the way agile teams write epics and decompose them into stories just in time for the target sprint. That’s an approach that benefits every software development team.

From Chapter 3: Building a Better Business Analysis Experience

“Three major (yet surprisingly simple to follow) strategies make the job of creating software requirements easier:

* Getting visual

* Getting social

* Getting going”

Blueprint advocates using diagrams, charts and graphs not just words, sentences and paragraphs. Visual representations are more likely to be understood and remembered. They also advocate frequent interactions and exchanges among team members. It’s not simply a matter of point-to-point communications, information has to be shared and accessible to everyone on the team.

While I’ve never used the Blueprint software and thus cannot recommend it, I can recommend the book as worthwhile reading. It’s concise and easy to follow.

photo credit: Lansing Public Library, Lansing Illinois via photopin cc

Build the Right Software

You can build the world’s best software system but if it doesn’t do what the customer needs, you’ve wasted time and money. For example, if you’ve built a system to generate comprehensive enterprise reports but the customer needs a system to do big-data analytics, you’ve failed. The reports may be easy to create and a pleasure to read but without the big-data analytics piece, they’re lipstick on a pig.

It’s astounding to me that this happens as often as it does. Everyone seems to think they understand what the “right software” is and what it needs to do. Yet when the system is ultimately delivered, key stakeholders conclude that critical features are missing. Then the blame game begins.

Build the Software Right

The other perspective is building the software right. Software that does exactly what the customer needs but is unreliable, fails. If the system was built is such a way that it’s slow and crashes frequently, no one will be happy. It’s great that it solves the specified business problem but if no one can effectively use it, what’s the point?

This too happens far more often than it should. There’s a joke among software developers who say “It works on my machine.” Just because the software works well in controlled environments like development and QA doesn’t mean it will work in real world environments.

There’s No Simple Answer

So which is more important? Would you rather have good, reliable software even it’s missing critical features and functions or poor, unreliable software that includes all the things you need it to do?

It’s clearly a rhetorical question. You’d need a lot more information to answer it. What features are missing? How often does it crash? Can the missing features be added quickly? Can the software defects be fixed readily? Of course, most delivered software systems fall between these two extremes — some features are missing and some aspects of the software are unreliable but, in general, things usually work fairly well.

Here’s the problem. When features and functions are left out — completely left out as in no one considered them — adding them to the system after delivery may be an incredible amount of work. The software may need to be deconstructed and rebuilt to include the missing pieces. Imagine building a house and failing to include a bathroom at the far end of the structure. Carving out the space and running the piping could be an enormous job. It would have been simple when the house was merely a shell, but not now.

Reliability problems discovered late in the effort are not so easily corrected either. I’ve seen software systems taken apart and reconstructed to resolve performance problems. I’ve seen defects that appeared to be minor result in major changes to the code. Imagine that bathroom again. If the plumbing and electrical services are inadequate to meet the needs of the bathroom fixtures, major rework will be needed to upgrade those systems. It will be highly disruptive.

You Can Have It All

It appears that the lazy answer — “…they’re equally important…” — may be the best answer. We need to define the software right and we need to build it right. Ultimately, it takes both to deliver great software.Why settle for good or adequate when you can deliver great?

How do you do that? Follow basic agile development principles.

• Be sure that the business and technical teams collaborate early and often.
• Deliver working software regularly and schedule formal review meetings to get feedback.
• Expect changes and be open to new ideas.
• Study software frameworks and good design practices. Use them!

photo credit: marsmet471 via photopin cc

But the news isn’t all depressing. Scrum provides excellent guidelines for delivering great software. Let’s look st those perceived problems more closely.

Scrum is incomplete — and so is every other software development approach I’ve ever seen. Any approach that has wide applicability will be incomplete when applied to your specific situation. Your environment, people and business rules are unique. If you’re looking for a development approach customized to your situation, you need to hire a consultant/coach to work with you for several months or more.

Scrum is unpredictable — when the people using it are not disciplined. Don’t blame Scrum if your backlog is out of control. Don’t blame Scrum if you can’t predict what will get released when. No development approach will make up for your lack of discipline. People solve problems. People deliver software. Scrum can help enforce some discipline but people need to be fully engaged in the effort and properly trained.

Scrum is chaotic — when no one steps up and provides leadership. Teams need oversight and direction. Scrum offers opportunities to oversee and direct every day — if applied correctly and supported by a good Scrum Master and a strong Product Owner. If the development team implements Scrum without adequate business support, it will indeed look like the developers are out of control.

Software development is not easy.

Wouldn’t it be great if there was a pill for software development? Give two of them to each developer every day for six weeks and out pops great software! Crazy, right? Yet, that seems to be what many people are looking for. They want a simple, lightweight, development process that includes step-by-step instructions and delivers great software.

Delivering great software is hard work.

Software development is highly complex and so are the risks. The degree of complexity and level of risk reflect your underlying business model. Small firms with simple needs can build simple software systems with relatively little risk. Large firms with complex needs have to build complex software systems and take bigger risks.

Thankfully, there are huge benefits to companies and their shareholders when software teams deliver what the business needs. It’s usually well worth the risk.

Let’s stop blaming the approach and the tools when software projects fail. In the end, people make all the difference. If your people are misaligned with your approach, you will fail. It doesn’t matter which development approach you select. Stop blaming your approach. Start training and supporting your people.

photo credit: DavidR_ via photopin cc

Change of scope.

What is scope creep? It’s a risk faced by projects that try to lock down the business requirements at the outset of a project. Once the requirements are locked, any request that results in additional work causes scope creep. Every time the business stakeholders change a requirement or add a new one the project manager yells “change in scope” to squeeze more time and money out of the business.

Unmanaged scope creep is bad because if work is added without extending the schedule or allocating additional people, the risk of failure increases. In theory, if scope is properly managed, it cannot creep — approved changes with associated impact assessments don’t increase risk.

You stay on your side. I’ll stay on mine.

Unfortunately, scope often becomes a kind of demilitarized zone between the business and development teams. The business team encroaches into the DMZ in search of capability they need but may have omitted. The development team fights back claiming the requested capability is additional work requiring a change request and schedule/budget increases. Each side digs in to protect its interests.

Agile software development projects don’t have to deal with scope creep because they let scope float. It’s a fallacy to believe that scope can be locked down on any enterprise-scale project. It’s impossible. Business people cannot predict the future. Their needs are constantly evolving and growing. What they need today — right now — will not be the same as what they’ll need in a few weeks or months.

Gold plating only makes it worse.

Some businesses attack the prediction issue by piling on software features in anticipation of what their needs will be in the future. That’s called gold plating and it’s equally bad. Gold plating the requirements results in bloated software that takes longer to deliver and is harder to use. Worst of all, it’s unlikely to meet the predicted needs of a rapidly growing business.

The scope of an enterprise-scale project cannot be fully determined and locked down at the outset. Any attempt to do so is foolhardy. It’s time to abandon the concept of scope creep. If scope isn’t locked down, it can’t creep. We also eliminate the need for change control and all the paperwork and review cycles that go with it.

Schedule and budget can and should be tightly controlled. Go ahead. Establish an end date (with some intermediate milestones). Allocate funding with a not-to-exceed dollar figure. Let scope float as needed to hit the date and meet the budget.

It’s less combative and it’s much easier to manage.

photo credit: Petirrojo via photopin cc

Tuckman articulates four stages of team building — forming, storming, norming and performing. In the forming stage, most people tread carefully. They are getting to know each other and want to be accepted. In the storming stage, people let their feelings out. Some are likely to argue and even confront those with whom they disagree. This can be unsettling to the quiet types on the team.

In the norming stage, cooler heads prevail. People try to work things out and accept ideas they may not be entirely comfortable with. They recognize that the success of the team transcends their individual success. Finally, in the performing stage, teams begin to function as a unit. Team members help each other out and classic swarming behavior manifests itself. Only performing teams can be self-organizing — as specified in the agile manifesto.

Note: Tuckman later added a fifth stage, adjourning. That’s when the team is disbanded either because the project is done or the company abandons it. I’ll ignore this final stage for this post.

It’s a Process

Clearly, it’s not easy or quick for go from forming to performing. It’s not necessarily a linear progression either. Teams may get stuck in a stage or even revert back to an earlier stage and be forced to try again. How does that happen?

Adding a team member or replacing one creates a whole new dynamic. Teams will usually drop back one stage or even go back to the beginning of the process. The good news is that they may advance through the stages more quickly so the setback doesn’t have to be severe.

Managers may also disrupt the process. When team members are storming (i.e. arguing), many managers will feel the need to intervene and settle the differences. It seems like the right thing to do but it sets the expectation that the manager will settle every dispute. This traps the team in the storming stage — a stage they may never be able to exit.

The Team Needs to Take Control

It’s for this very reason that command-and-control development processes inhibit the formation of high-performing teams. Everyone expects the organizational manager to make decisions, break deadlocks, and resolve conflicts. The team merely carries out instructions. They avoid taking any risks and they avoid taking (individual) responsibility for many of their actions. Everything is decided either by management or by consensus.

If management makes the decisions, there will be a major bottleneck. If consensus makes the decisions, the process will be slow and will likely result in the infamous “design by committee” solution (whereby everyone gets something they want and the resulting product is a hodge podge).

Team Building Needs to Be Agile

To get software development teams to the performing stage fast, start delivering working software as soon as possible. Teams need to feel comfortable taking risks. They need to fail fast, recover quickly and learn from every experience. Agile development techniques should prevail.

In the forming stage, leadership is essential — even if it’s an organizational manager doing the leading. Preferably, the Scrum Master or Product Owner will step up and make decisions. Get everyone on the team engaged in the effort as quickly as possible.

In the storming stage, the team needs to sort things out. The SM or PO should offer guidance and let the team work out the final decisions. There’s a danger that one or more team members will intimidate others or timid members may simply not speak up. The SM and PO can help calm nerves and draw everyone out. It’s fine to enforce a code of conduct on the team.

In the norming stage, team members become more open and collaborative. They begin asking for help. The team acknowledges that small failures are accepted. The focus is on continuous improvement not achieving perfection. The SM and PO can focus on their responsibilities letting the team run itself.

Finally, in the performing stage, agile teams become self-organizing. They work together openly and rush to help anyone that needs it. The SM and PO are there to advise and guide the team.

This process will take more than one sprint. Be supportive and give the team a little time to reach the performing stage.

photo credit: Mark Heard via photopin cc

Let’s explore what triple-H weather patterns and triple-H projects have in common. Once we understand the pattern, we can determine what development teams can do to minimize the problems it creates.

Hazy – In weather terms, hazy simply means limited visibility. In software terms, it means business requirements are not well-defined. The business stakeholders ask the development team to build a software system but the definition of that ‘system’ is vague and/or overly broad.

Hot – We all know what hot weather is. Hot software projects are those that have an abundance of senior management attention. This is good and bad. Personally, I like working on high-profile projects. It’s exciting. However, if a project gets too hot, managers may get unreasonable and overly demanding. When that happens, there’s too much administrative work and not enough development work.

Humid – Humidity is a measure of moisture content in the air. Humid air makes it harder to breathe. It makes us sweat and generally uncomfortable. When software projects put us under too much pressure, we also get uncomfortable and stressed out. We hurry and we’re prone to making mistakes.

Triple-H projects require special handling.

So if you get assigned to a triple-H project or your current project turns into a triple-H one, what should you do? The specifics will depend upon your situation, but here are some general guidelines.

Hazy – Business requirements need to be specific whether they’re in the form of requirements documentation or user stories. The software team doesn’t need to know every detail for the entire development effort. But at a minimum, they need to know what to do next. The short-term needs have to be clear and detailed. The long-term needs can be refined as they move up the queue. If the requirements for the next release are hazy, push back on the business stakeholders. Ask specific, detailed questions to pin down what features they need in the next release.

Hot – Hot projects can be tough. Lots of management attention can wear a team down. Telling senior managers to back off is not an option. You need to show that the team has the project under control. Start by communicating regularly. Be open about what is being done and why. When you’re asked questions you don’t have answers to, say so. Explain why the answers are unknown and estimate when you’ll have the answers. You need to build confidence in the team and everyone on it.

Humid – Being under a lot of pressure causes plenty of problems. Mental activities are disrupted. Physical functions are stressed. Emotions are maxed out. In these situations, teamwork gives way to combat. It’s important to diffuse the tension. Get everyone focused on the things the team can control. Tune out the noise. Deliver working software and everyone will feel better.

photo credit: canihazit via photopin cc

Have you ever taken piano lessons? Or, have you ever taken classes to learn a new language? If not, maybe you know someone who has. These types of learning situations can be tedious and boring when using old school techniques. In fact, many people give up because they can’t deal with the monotony.

Take piano lessons, for example. You want to learn how to play the piano. That is, you want to play some songs. Yet, the lessons begin by teaching you how to read music or telling you how a piano works. Most people really don’t care. They don’t expect to become concert hall pianists. They just want to play a few songs and have some fun!

The same kind of thing happens when learning a new language. Lessons begin with the alphabet followed by spelling and grammar principles. Again, most people don’t care. They’re not interested in becoming translators for the United Nations. You just want to carry out a brief, simple conversation such as asking for directions.

We crave a sense of accomplishment.

Thankfully, many teachers have figured out that learning has to be fun. They’ve discovered that it’s important to get students doing what they want to do early in the process. The piano student is taught to play simple songs as quickly as possible. The language student is taught to speak simple sentences early on. These techniques provide a sense of accomplishment and encourage students to try harder. The tedium of music sheets or proper spelling are interwoven with the fun stuff.

Both sides benefit. The teacher has fewer dropouts and the students learn more.

It’s the same with software development.

Now consider software development. The business stakeholders identify a software need. Managers assemble a software development team. The business community wants to begin working with the new software as soon as possible. The development team wants to begin writing the software almost immediately.

What usually happens instead? The development team is forced to write lengthy specification documents, conduct review meetings, revise documentation, seek approvals — blah, blah, blah. The developers are unhappy because they aren’t doing what they enjoy and value most. The business community is unhappy because they are supplying enormous amounts of information and getting nothing useful in return.

This old school technique is based on waterfall development principles. Is it any wonder that both software developers and business stakeholders lose interest in the project and move on?

Learn a lesson from modern piano and language teachers. Exploit the fun factor. Let the developers build something quickly. Engage the business community with working software as soon as possible. Everyone feels better and actively participates. The quality of the end product improves. That’s agile! It’s common sense, right?

photo credit: LodewijkB via photopin cc