10 Tips for Producing Documents That Are Lean and Agile

Some software development groups must document everything. This often results from legal, regulatory or compliance demands. Although, it can also be a cultural phenomenon — some managers simply won’t accept anything unless it’s in writing.

Do everything you can to minimize the volume of written exchanges. Information overload is not just a cute phrase. It’s real and it causes lots of confusion and errors.

Some reasons why you might need a (virtual) paper trail

Written artifacts are often used as a vehicle to get people to think. They also serve as verification that the thinking happened. The artifact itself isn’t what’s important. It’s the effect that it has on people that matters. The challenge lies in getting people to actually read the artifact.

Other written artifacts suggest or even enforce a process. For example, action “A” takes place and is documented. The document triggers action “B” (this scenario may be repeated multiple times during a project). This approach is particularly useful when different groups or even companies are involved in a collective effort.

Finally, written artifacts may serve as a historical roadmap depicting how the software evolved and describing the current implementation. As above, this can be particularly useful when multiple groups are involved.

Keeping the project artifacts from becoming a burden gives you a better chance of getting people to write them. Keeping the documents lean and agile gives you a better chance of getting people to read them.

If your team is spending significant time merely documenting as opposed to solving and delivering, you have a problem. I’ve observed many a developer spend vast amounts of time on document layout, formatting and pretty-printing. It doesn’t impress me and it won’t help your team deliver better software.

If you’re forced to produce large quantities of written artifacts, follow these tips for minimizing the burden.

Ten Tips for Writing Better Documents

• Focus on content not art. If fancy artifacts are required, use a simple, clean template. Be sure that the content captures the reader’s attention not the fancy fonts and artwork.
• Adopt the attitude that less is more. Deliver brief and direct documentation resisting the urge to write a novel. More of what you write will actually be read.
• Don’t duplicate content. Never copy and paste lengthy sections from one document to another. Always reference the source.
• Keep it informal. You may need some formal documentation but don’t write everything in a formal way. Make it informal unless formality is required. Often, a simple photo of a whiteboard is good enough. Why turn it into a fancy computer diagram?
• Avoid long, unstructured documents. Group related material into clearly defined sections.
• Use simple sentence structures avoiding long, compound sentences that are hard to follow. Also keep paragraphs short as whitespace improves readability.
• Use bullet points to slow the reader down and draw attention to important ideas that don’t need to be understood in a particular order.
• Use numbered lists to draw attention to information that should be read in the order presented.
• Include graphs, charts and photos for improved understanding but don’t go overboard.
• Take advantage of bolding, colored text and links to highlight words and draw attention to them.

Documentation is important. Formality and bulk are not. Keep it lean and agile.

Do Agile Development Teams Need Multiple Product Owners?

Enterprise agile development is different. Developing software using Scrum, Kanban, Lean or XP is just not the same on an enterprise scale. Consider the stressed-out, over-burdened, Product Owner.

Is it reasonable to expect one Product Owner to provide all the answers to the software development team’s questions? You can argue that it’s the Product Owner’s responsibility to seek out the right people and get the information. However, that adds a layer of indirection that could slow the team down or result in wrong answers.

Consider an analogy from the construction industry. Have you ever had a house built or had a major renovation done to your house? You hire a general contractor. That person hires specialists for each aspect of the job. For example, the general contractor may subcontract with the following businesses:

• Plumbing Contractor
• Electrical Contractor
• HVAC Contractor
• Carpenter
• Roofing Contractor
• Insulation Contractor
• Painting Contractor
• Flooring Contractor
• Landscape Designer
• Interior Decorator

Each business will have its own designer/planner to plan the work required, estimate the cost/time, and bring in the appropriate people. The general contractor relies on the specialty experts to provide answers and solve problems. No one expects the general contractor to have all the answers.

Product Owners Are General Contractors

In agile software development projects, we require that one person take ownership of the entire effort and provide all the answers. Is that reasonable? Here are a few areas that may require specialization:

Business Relationship Owner – This person builds trust with the business community (customers, clients, partners and internal users). Keeping all of these groups engaged throughout the project is critical.

User Experience Owner – Apple has proven that providing an elegant and polished user experience is a critical success factor. It’s a highly specialized skill that few can provide.

Technology Toolset Owner – The toolset used to build the software is often critical in enterprise development. Deploying a .Net solution into a Java environment (or vice versa) makes little sense. Someone needs to own the toolset decisions.

Information Architecture Owner – Many enterprises are drowning in data. They need solid information taxonomies and architectures to leverage their information and extract full value from it.

Externally Accessible Services Owner – If customers and partners will be accessing software services externally, someone needs to decide what the services will be and how they will be presented.

Externally Accessible Data Owner – If company information will be made available to outsiders, someone needs to decide what information will be offered and how it will be controlled.

Regulatory Compliance Owner – Every company faces legal, regulatory, industry and government compliance issues. It’s unlikely that anyone on the development team has this knowledge.

Documentation Owner – User guides remain critically important even if they are online and never printed. Good user documentation can reduce customer support calls and save money.

Marketing Owner – Someone has to convince people to buy the software or service. That person will need to define the value proposition to the customer and ensure that the software delivers it.

You get the idea. The Product Owner is not all of the above. The Product Owner is the general contractor. He brings in experts as needed. Not all of these experts will be needed for every project but they should all be identified and kept informed of the project status.

photo credit: Cayusa via photopin cc

Avoid a Project Blamestorm. Agile Development Can Help.

Have you ever been asked to deliver a software solution only to discover that the requester doesn’t know what she wants? In addition, she gives you a deadline, yet when you question the relevance of the target date, it becomes apparent that the deadline was picked at random.

It’s happened to me more times than I can remember and I have no respect for people that do it. They believe they’re assigning work and managing deliveries, when they are giving birth to a disaster.

It’s a blamestorm waiting to happen.

Fortunately, this is the ideal situation to use an agile software development approach like Scrum, Kanban, Lean or XP. There’s no better way to nail down what someone really wants (and needs) than to start building it. Throw together a quick mockup or wireframe. Try out a few ideas. Explore the solution space.

Tradeoffs have to be made

If there’s a good working relationship among the responsible parties, everyone will realize how big and complex the request really is. They’ll be able to rough out a solution and even estimate a target delivery time frame. Neither the solution definition nor the time frame will be precise because many details will remain to be worked out.

If the software is needed in a hurry, the requester will need to control the scope tightly. If feature set and quality are more important than timing, the initial deadline likely won’t be met. (You can’t have it all. Deal with it!)

Building trust makes it easier

The way to make this work is to build trust among the key players. You build trust by seeking areas of agreement. I’m often asked questions like “Is this possible?” or “Can that be done?“. The flip answer is “Of course, anything is possible.” The real and practical answer is more like “It depends.” — it depends on time, money, people, priority, etc.

I always try to offer a specific approach. For example, if I’m asked if the software can send an email message, I might offer that while it can, a simpler approach would be to log the item in an already existing log file. If the requester likes my suggestion, we’re good to go. If not, we can have a conversation around what’s needed and why.

This approach is far better than saying “No, it’s not possible” (none of us likes to hear ‘no‘). Also be careful with a simple “Yes, it can” response. It will likely leave the impression that the request is simple when in fact, it may be difficult and outside of time and cost constraints. Be clear. Be honest. Be agile.

photo credit: dave~ via photopin cc

Motivation Doesn’t Just Happen. You Need to Work At It.

If you’re married or have a close friend, you know how much effort it takes to maintain a healthy and positive relationship. Frequent interactions are mandatory. Open communications are essential. Slack off — even for just a few weeks — and the relationship suffers.

So why is it that many managers rarely interact with their teams. And when they do, it’s to give instructions or orders. Those managers don’t have a relationship with their people at all. The company controls the relationship and it amounts to “I’m the boss. Do as I say.”

That’s a buzz-kill!

Here are five suggestions for motivating your team members and building relationships with them. Try to keep it low-key and genuine.

1. Be generous with praise. Everyone likes to be praised. It doesn’t cost the company any money and it’s easy to do. Praise people privately. Praise them publicly. Encourage senior managers and executives to do it too. Praise from the boss’s boss is extra special.
2. Empower the team. Let them make their own decisions rather than constantly seeking approval from management. No one wants to let their team down. They’ll work harder and be happier. Lead, don’t control.
3. Take a team member to lunch occasionally. Make it a surprise not a policy. Walk up to someone and invite them to lunch with you. Minimize the shop talk and get to know each other.
4. Give recognition and small rewards. Offer a shout out to someone in a team or company meeting. Issue a challenge and make it a contest or a game. Have fun with it.
5. Have a party. Group activities go a long way. Have a picnic. Organize birthday parties. Hold a happy hour. Find a reason to celebrate. Don’t wait for a holiday.

It’s great if you can afford to offer rewards to people. This may be difficult as some companies are real tightwads. Here is a bunch of ideas for rewards. Some are cheap and some aren’t. Provide rewards and incentives as gestures of appreciation for an accomplishment. The reward should be timely, direct, personal and specific. Try to match the reward to the effort made.

Reward Ideas

• Bag (there are many options)
• Bonus
  • Gift card
  • Cash
  • US Savings Bond
• Clock (desk, wall or wrist)
• Dinner certificate for two
• Gadget (elegant or fun)
• Hat or cap
• Jacket or sweater
• Limousine service
• Mug or glass
• Pen
• Personalized reward based on …
  • Family Situation
  • Hobbies
  • Personal interests
• Pin with slogan or motto
• Pocket knife/toolset
• Points (to be accumulated and cashed in)
• Shirt
• Special event
  • Bowling
  • Group lunch or dinner
  • Group movie – rented or at a theater (supply food, popcorn & soda)
  • Paintball
  • Picnic
  • Pizza party
  • Roller/ice skating
  • Trip to the mall to buy a gift or have some ice cream
• Special project or time to work on a pet project
• Sweatshirt
• Tickets to a movie, play or event
• Time off with pay
• Trophy or plaque
• T-shirt
• Vacation trip
• Water bottle
• Weekend getaway

Surely there’s something on this list you can do? Be sure to engrave or embroider personal items. Use your imagination. Motivation doesn’t just happen. You need to work at it.

photo credit: rosipaw via photopin cc

Building the Software Right Doesn’t Make It the Right Software

Information technologists and software developers do not know best. We are not the definitive experts on what software systems to build. Simply building the software right is not enough. It has to be the right software.

I see too many projects dominated by IT or R&D. It often starts innocently enough. The technologists come up with an idea and implement a software prototype. They demonstrate it to the potential business stakeholders, who are impressed. There is a consensus to move forward and build the software system.

Sounds good, right?

So the technical team carries on until they reach a point where they have something that the target group can try out. (This often takes months, which doesn’t help matters.) The software is deployed into a test environment and a limited group of people are allowed to use it.

Inevitably, as more people get involved, more ideas are generated — some of those ideas will be in direct conflict with the work already completed. This is where things begin to go wrong.

The target group wants to change some aspects of how the software operates, how it looks, and how it responds. The technology team has become attached to the current implementation and resists significant changes. The battle lines are drawn. The project may wither and die or it may proceed after a long, drawn-out political battle. Both outcomes look and feel like failure.

Where did things go wrong?

The software developers built the software right but they didn’t build the right software. This situation didn’t have to happen. The project went off course at the very beginning. At the outset, the technology team should have built a quick and simple mockup of the software. This could have been as simple as a wireframe or they could have used a GUI design tool to create a more polished model.

Either way, little time would have been expended and no one would have become overly attached to the end result. Once approval was obtained to continue with the project, an executive sponsor and a core group of stakeholders should have been selected (hopefully, they would have self-selected).

Then the combined business and technology team could have defined requirements or stories, specified the target users, and established goals for a minimum viable system. This collaborative approach makes people feel valued and engaged rather than dumped on and manipulated.

How do you approach new software initiatives? Let me know.

photo credit: Dean Terry via photopin cc

Software Delivery Problems? Focus on Relationships Not Process.

Here’s how the situation unfolds. An enterprise company experiences problems with their software development efforts. Software systems are delivered late. They are poor in quality. They lack important features. Or in some cases, they are never delivered at all. What’s the solution? (This is not a quiz!)

Tighten the process! Institute more controls, more metrics, more reviews and more approvals. You’ve heard of “running a tight ship”, right? That will fix it … Or not.

Let’s ignore the effect of all that tightening on team morale and think about the process flow. More management oversight means managers will need to spend more time monitoring projects — they will need to be more involved. That likely means more managers will be needed. More managers means more meetings. More meetings means more administrative things to do. More … you get the idea. More of everything — except productivity.

Here’s the final result.

• Software systems will still be delivered late (unless schedules are greatly extended) and projects will surely cost more.
• Quality may improve but only if quality is more important than meeting dates (unlikely).
• Important features won’t get missed or forgotten but they will still be dropped to “get back on schedule”.
• And, yes, some projects will still never be delivered at all because all those managers won’t agree on specifics.
• Oh! And one more thing…there will be increased infighting and political battles resulting in poor morale and lost productivity.

Moral of the story: Throwing more process at a broken process introduces more break points.

You need to look at a broken process completely differently. Instead of asking, “What changes can we make to the process?”, ask, “Why is the process broken?” and “What caused it to break?”. Most often you’ll find that relationships are broken. Failed relationships cause processes to fail. Tightening the process does nothing to address the relationships that form the foundation for any process.

If those relationships remain broken, no process changes will ever fix the problems of late, poor and missed deliveries.

Fixing relationships can be difficult but it has to be done. Start by initiating a conversation among the stakeholders. Ask what each stakeholder needs from the software and the process. Then listen, really listen. If someone feels he/she has been wronged, apologize. Don’t be proud, just do it.

Relationships are built on trust. Work on rebuilding and strengthening trust. Collaborate more, don’t just communicate. (Copying someone on routine email messages or status memos is not collaborating. It’s throwing information over the wall.)

Once those relationships have improved, assess the development process with an eye toward simplifying and decentralizing it. Process should help people get their jobs done. As soon as it starts to get in the way, you’ve gone too far.

photo credit: lumaxart via photopin cc

7 Tips for Improving Your Software Development Process

Can we agree that writing great software is hard to do? Not just any software, great software. Every corporate situation is unique and there are no simple solutions for building great software. That said, here are seven quick tips for improving your software development process. Pick one or two and get to work.

1. To speed up your development cycle, slow down.

The harder you push to finish the software, the more mistakes you’ll make. Items will be missed, decisions will be wrong, shortcuts will be taken, technical debt will accumulate, and quality will suffer. Instead, prioritize and focus. You’ll get less done, faster.

2. To ease decision-making, keep it simple.

The more options you offer someone, the more questions they’ll ask. Confusion and bewilderment are the likely results. Evaluate priorities and needs, then offer fewer choices based on them. You’ll reach consensus easier and faster.

3. To be better at what you do, prepare, practice and deliver.

Basic agile principles are fairly simple — even obvious. Implementing them is hard work. Lots of preparation and some early failures are the price of admission. Don’t let the difficulties discourage you. It’s worth it.

4. To deliver big changes, start smaller.

We often try to do too much, too quickly. Change can be overwhelming when not handled in a structured and disciplined manner. Big changes carry big risks and extended approval cycles. Bite off small chunks. Digest them fully and keep at it.

5. To build better business relationships, stop telling.

Smart people often talk too much and listen too little. Business people don’t need you to tell them how to run their business. They need you to listen to their problems and concerns so you can help them find better solutions.

6. To learn quickly, fail faster.

The best way to learn is by doing. Anticipate rookie mistakes and leverage them to learn. Early sprints or iterations are good for experimenting, failing and learning. Take advantage of them. Don’t let perfection get in the way of greatness.

7. To differentiate your team, develop subject matter experts.

Writing great software is not enough. The business needs people who are experts in their specialized domains. These domains need to cover business and technical areas that are relevant to the business problem being solved and software system being delivered. Be a SME.

Got any other suggestions to share?

photo credit: cdw9 via photopin cc

Enterprise Agile Development Takes Positioning, Preparation and Passion

Getting a big company to change the way it operates in any meaningful sense is always tough. They invest lots of time and money in establishing best practices and training people to follow them. Change happens but it’s never simple or quick when hundreds or even thousands of people are involved.

This causes major issues when changing from waterfall software development to agile software development. To combat the problem, companies often invent hybrid development approaches that are never truly agile. Hybrid approaches address a few key areas. Things get a little bit better. Management loses interest and the change effort ends.

That’s a shame. It amounts to leaving money on the table. Getting big companies to change takes more than just presenting an idea and asking for support.

It takes Positioning, Preparation and Passion.

I’ve discussed this three-phased approach to agile adoption in a post I wrote for Colabpro. The post is called “How to Be a Successful Agile Development Evangelist”. Think about the term ‘evangelist’ — someone who is enthusiastic about an idea, likes to tell other people about it, and wants to see it grow. Combining that with Positioning, Preparation and Passion is the path to successful enterprise-agile adoption.

Please take a look and let me know what you think by leaving a comment at Colabpro or here.

photo credit: joiseyshowaa via photopin cc

Agile Risk Management Won’t Make You Cringe

Mention “risk management” and many software developers will cringe and sneak away. It’s understandable. I’ve observed some elaborate risk analyses covering everything from missed requirements to flash floods. I cringe just thinking about it!

You could go to extremes in preparing an elaborate risk assessment matrix covering probabilities, impacts, mitigation steps, etc. If you’re going to invest in such an effort, you really need to commit to keeping the risk analysis up to date. Face it, risks change over time, their likelihoods fluctuate, their impacts grow and shrink, and the mitigation steps change. You’ll need someone who spends most of his time managing the risk assessment!

Are you ready to commit?

The biggest problem with this legacy approach to risk management is that it treats risk as a separate artifact. It’s something else to manage outside of the development process and apart from the team. It gives managers something to do…I guess. After all, someone needs to worry about flash floods, right?

In reality, risk is everywhere. It’s in every requirement, every story, every feature, every communication, and every line of code. Disassociating risk from the rest of the project is like treating the smell of food as completely independent from the taste. Try holding your nose the next time you have dinner. Let me know how that works out for you.

Agile teams manage risk every day.

Managing risk is an integral part of agile software development. Daily stand-ups, integrated testing, frequent deliverables, business participation, and regular production updates are all intended to reduce risks. Most people don’t think about the core agile development practices in terms of risk management but they should.

Getting people engaged and communicating is central to agile teams and essential to managing risk. When someone senses an imminent problem, they’ll speak up and offer mitigation ideas. When something has been missed, it gets caught early and addressed. When mistakes occur, they’re spotted quickly and corrected.

Agile developers are risk averse and manage risk daily. They may not think about it that way but it’s true. How agile are you?

photo credit: mag3737 via photopin cc

Great Agile Development Teams Are Never Satisfied

Greatness is hard to achieve and even harder to maintain. Few agile software development teams ever achieve greatness and that’s probably a good thing — they wouldn’t be happy anyway.

The best agile teams never get complacent; they never stop improving; they never get too comfortable; they are never happy with their performance. The good news is that you don’t have to be miserable to keep improving — though it helps.

Misery loves improvement.

Let’s look at this from another perspective. Say we have a software development team that is the best it can be. There’s no need to get better; nothing to prove; life is good.

How long do you think that state of greatness would last? I’d say about as long as it takes for the business to conceive a new idea or for underlying technology to change — not more than 3-6 months, probably less.

That’s why continuous improvement is so important. I see many development teams adopting an approach — a process and it’s operational procedures — and using it over and over, project after project. Even when their outcomes are only fair at best, they continue to follow the prescribed approach in the belief that if they do it often enough, they will get better. They won’t!

Repetition makes us better at doing something as long as that something is static. For example, a complex software application may be difficult to use at first, requiring lots of time and patience. As you repeatedly use the software, you get better and faster until you’ve mastered it.

And then the vendor delivers a major update!

So it goes with software development. The business changes. The tool set changes. The team changes. The technology changes. Even the rules change!

Continuous improvement is essential. Retrospectives are a great way to drive improvement regardless of your approach to software development. Even if your deliverables drag out for months, you can conduct regular retrospectives and seek continuous improvement throughout the project.

Whatever you’re doing today is broken, you just don’t know it yet. Don’t wait to find out.

photo credit: raleighwoman via photopin cc