Perform Work Iteratively To Be More Productive and Efficient

Some people have a hard time accepting iterative approaches to getting work done. It may be because many of us have an innate desire to finish something — we need to be done. Yet, when we iterate over a work item, it feels like it takes longer to get to done. Here’s a simple example taken from everyday life.

Let’s say you want to clean your entire house or apartment. Cleaning one room at a time seems like a good approach. You’d get a sense of accomplishment after finishing each room. But it’s not efficient. You’d be switching among cleaning products and cleaning tools — constantly wrapping up one task and preparing for the next one. You’d also run the risk of stopping before you ever got to little used areas of your home (which is why you should start with the least used area).

A more efficient and ultimately faster approach is to break up the housecleaning task into iterations where each iteration is focused on a particular cleaning task. For example, your iterations might look like this:

1. Pick up all the clutter throughout the house and put items where they belong.
2. Prepare for window cleaning and wash all the windows.
3. Prepare for furniture dusting and dust all the furniture items as needed.
4. Vacuum every room including drapes, upholstered furniture and floors.
5. Prepare for floor washing and wash any remaining solid floor surfaces.

The downside is that you won’t get that same sense of satisfaction of being completely ‘done’ with a room until later. The upside is that you’ll finish the entire job sooner. Another upside is that this approach is more readily adaptable to multiple people doing the cleaning. Once step one is completed in a room, someone else can begin step two in that room and so on. The cleaning crew won’t be competing for cleaning items as they would in the one room at a time approach.

Anyway, it’s a simple example intended to make a point. There are many jobs that can be done more efficiently and faster by iterating over the solution space.

Writers Do It

Another great example is the job of writing any lengthy document. It can be a novel, short story, article, specification or presentation. Writers have been doing it for centuries. They don’t plod through documents one section at a time. The efficient process goes something like this:

1. Create an outline. Layout the major sections.
2. Make a complete pass through the document filling in the quick and simple parts.
3. Make another pass adding details and supporting information.
4. Make a final pass filling in missing pieces.
5. Lastly, check, double check and wordsmith the entire document.

Agile Developers Do It Too

For agile software development, the same rules apply. The iterative process is similar and might look like this:

1. Create a structure or foundation for a code module.
2. Make a complete pass to get basic functionality working.
3. Make another pass to add complex functional elements.
4. Make a final pass for error handling and logging.
5. Lastly, check everything and integrate the module with the rest of the system.

The precise details will vary depending on your skills, style and confidence. The point is that iterating over the solution space is ultimately a superior way of getting things done. Plodding through any job trying to completely finish one area before moving to the next one is inefficient and costly. You’ll inevitably be forced to go back and adjust something you thought was done.

Embrace the feeling of being ‘done’ when completing each task — not just when the entire job is compete.

photo credit: bandita via photopin cc

Agile Project Management Works for Small Businesses

Guest Post

I’m pleased to share this post written by the folks at Agil8.

Project management systems are not methods that are just for big businesses and large-scale organisations alone. They are also suitable for smaller businesses that can benefit a great deal from these methods too.

The fundamental principles of project management can be successfully applied to all businesses regardless of their size. Agile Project Management methods are now being adopted by small businesses across a broad range of sectors, in order to carry out a variety of different types of projects successfully.

What Is A Project?

A project describes any type of activity that is carried out alongside, or in addition to the usual day-to-day running of the business that requires specific attention within an agreed and established timeframe.

What Is Project Management?

Project Management involves the planning and establishing of objectives, allocation of a budget and the distribution of responsibilities within a team in order to work towards a goal or objective. Traditionally this has meant a team working under a project manager who controls and is responsible for the project.

What Is Agile Project Management?

Agile Project Management uses modern methods which differ a great deal from the more traditional approach to project management. Agile Project Management methods embrace a highly versatile approach which allows a team to define a clear objective, then evaluate and adapt the path of the project together, in stages as it develops organically.

This flexibility has great advantages over the more traditional methods which plan the entire project in advance and work towards the objective following that plan, regardless of any changes that may occur along the way. This type of rigid planning is highly inflexible and makes no allowances for any potential obstacles, or changes.

So How Can Agile Project Management Help My Small Business?

A project can enable your small business to be innovative, in order to grow and expand. Perhaps your objective is to attract new clients in order to increase sales and boost revenue, or maybe you are keen to diversify in order to broaden your current business opportunities.

Whatever the objective, a project when it is planned effectively and well coordinated and evaluated at each and every stage, can help your small business to achieve its desired goal. With Agile Project Management, the whole team of employees within the business, pool their skills and resources and work together to achieve the objective of the project through careful planning, communication and teamwork. Tasks are shared and allocated to team members according to their particular skill or expertise.

Each project is approached in small iterations, or ‘mini-objectives’, based on short time scales. The team meets regularly to evaluate progress and plan and coordinate the next step. This highly flexible and interactive approach to managing a project allows the team to react to any internal or external changes as and when they arise, quickly and effectively. At times, certain changes will significantly alter the path of the project and this is where you can appreciate the real benefit of working with Agile Project Management which is designed to adapt and respond to change in a positive way.

This flexibility is a crucial, key element in any Agile Management Project; therefore any businesses that prefer to adhere to strict project processes would not find this particular way of approaching project management suitable for them.

Agile Project Management – What Are The Real Benefits?

Because Agile Project Management involves the whole team, who collectively share responsibility for a project, it tends to have a very positive impact on team morale and the whole working environment. Individuals feel far more focused and motivated and it is this boost to team morale that has a knock on effect on levels of productivity and performance, which will in turn increase revenue.

Go For It!

In reality, the need to manage budgets and deadlines and to satisfy your customers and clients with efficient delivery of your product or service, is identical and of equal importance to that of any other business, just on a slightly different scale. The fact that your business is small does not mean you should shy away from project management, or do not need it and should just stick to what you are doing already.

Agile Project Management can support your small business and make it more successful through effectively managing your projects in a flexible manner with the involvement of your whole team.

Guest Author: Agil8 offers the highest quality Agile consulting and training. The company was formed by David Hicks, a pioneer of Agile since the mid-1990s, an Agile Alliance Founder and one of the world’s most experienced and qualified Agile consultants and trainers. Agil8 draws on experience of working with organisations across all industry sectors over many years, and the management and delivery of some of the world’s largest and most complex Agile implementations.

Image Credits: shutterstock

If You Develop Software in Iterations, Are You Agile?

Let’s say your team deploys a new software release every four weeks. (I’m a big fan of short release cycles. In fact, I think four weeks is too long but let’s try that.) On the surface, the team appears to be using an agile development approach. But let’s stir the pot a little.

What if I tell you that the team spends the first week of each cycle planning and designing? They have a rule stating that the content of the next release must be finalized during the first week. Change requests are allowed but usually deferred until the next cycle. They spend part of the first week documenting and designing the changes. (Hmmm, this “agile” approach is starting to show some wrinkles.)

The team implements the features that made the cut during weeks two and three. The developers perform unit tests and fix the defects they discover. Toward the end of week three, they package the software and deliver it to the quality assurance team. (At least, that’s how the process is supposed to work. At times, development runs late and spills over into week four.)

During week four (or what’s left of it), SQA tests the software and reports defects. If time allows, developers fix the defects and send another build to SQA for testing. If time doesn’t allow, the known defects are noted in the release notes and SQA testing spills over into the next cycle (or simply stops). Defects found beyond week four may not get fixed in the next cycle if they miss the week one planning window.

Iterative, yes. Agile, no!

I try to stay away from dogma. For example, ‘to be agile you must have daily standup meetings’ (the team has to stand or it doesn’t count). Or, ‘you can’t be agile if you use sprint zero, hardening sprints or any other technique that doesn’t focus on completing user stories’.

But there is one principle that I steadfastly maintain — to be agile, the business, development and SQA teams must collaborate. (In an ideal world, there would only be one team and collaboration would be simpler. The world is not ideal. Get over it.)

True collaboration must happen every day, not every fourth week. SQA should be testing new builds daily (you are doing daily builds, right?). The business should be actively involved in the development process daily (you told them they must be engaged in the effort, right?).

Iterative waterfall techniques work in some environments. If you absolutely, positively must use waterfall, please iterate. However, if you want to be agile, you must collaborate. There is no substitute.

photo credit: jaygoldman via photopin cc

Management By Proxy and Agile Development Don’t Mix

Following the rules isn’t good enough.

Do you manage by proxy or are you being managed by proxy? It works like this. A manager or management team defines lots of rules — you must do this — you cannot do that. Been there? Some of the rules are sensible like those related to timely response and quality control. Others, not so much, like those that call for filling out forms or submitting requests for every issue no matter how small or insignificant.

The manage-by-proxy manager simply monitors compliance. His first response to any question is “Did you follow proper procedure?”. If your answer is no, you’re told to go back and follow the procedure. If your answer is yes, you’re told what the next step is according to the procedure.

I’m calling this “management by proxy”. The proxy is the procedure. That’s a management job you gotta love. Just pull out the rule book, find the appropriate entry and read it. The rule book manages the team not the manager.

To my shock and awe, some employees actually like this approach. They know exactly what they need to do (and not do). They believe that as long as they follow the rules they have nothing to fear — even if something goes wrong. Disaster may strike but as long as you followed the rules, you’re protected.

Those who create need more.

The approach works in many situations where people are performing jobs that demand accurate repetition — the same work must be performed in the same manner repeatedly. The end results are well known. The number of things that can go wrong is constrained. Makes sense, right?

Enterprise software development is different. The end result is often envisioned but not known. The number of failure types is difficult to quantify. Management by proxy is often attempted but rarely works. You’d need a rule book the size of a multi-volume encyclopedia.

Agile self-organizing teams and rule books are hard to mix. We all need to “know the rules”, of course. Yet, one of the best kept secrets to successful agile development is letting the team figure out the rules as they go. And, empowering them to change the rules as needed.

Skip the Encyclopedia

If you’re a manager with a background in management by proxy, learn to let go. That will only happen if you have respect for your team. Be open-minded and transparent. Be willing to accept small failures as learning opportunities.

If you’re a developer accustomed to management by proxy, learn to rely on your teammates. The best agile teams show mutual respect and help each other. They swarm to the aid of any team member in trouble.

Rule books don’t create great software. People do.

photo credit: two instincts via photopin cc

You Want to Change Your Software Development Approach, But How?

If your team follows a traditional, legacy approach to software development and wants to convert to an agile approach, how should you go about it? Let’s say you want to convert from a waterfall approach that uses a strict command-and-control model to Scrum that uses a self-organizing team model. How would you get from here to there?

There are many ways to undertake this change. None of them are quick or simple. Small organizations are more likely to succeed than big ones simply because they have less invested in the status quo. Big organizations have much to protect and preserve.

Here are two extreme examples of how you might proceed:

1. Dump everything you’re doing now and adopt all new techniques. Don’t consider anything sacred or untouchable. Change everything.
2. Change one thing, try it out, let it settle, then change something else. Approach the switch slowly and deliberately.

Which option is better? Which option will produce the better outcome? It’s up to you.

Advantages of #1

• Gets all the pain and discomfort out in the open immediately. Lets everyone know what’s going to change.
• Allows the team to focus in building competence with the new approach. There’s nothing to preserve.

Disadvantages of #1

• Causes maximum disruption which might jeopardize a product or service release.
• People may get confused and frustrated increasing the odds of the new approach failing completely.

Advantages of #2

• Minimizes the pain and discomfort making the transition manageable.
• Allows the team to focus on just one aspect of the new approach at a time building expertise as they go.

Disadvantages of #2

• Spreads out the pain and discomfort over a long period of time creating a difficult work environment.
• Increases the odds that the new approach will never be fully implemented.

If you select #1, be ready for plenty of turmoil. Offer lots of support, training and coaching. Be willing to accept some small failures and some employee turnover.

If you select #2, be vigilant. Keep pushing new ideas and new techniques. Do not accept “good enough”. Keep marching toward the final goal.

Shorter Is Better But It’s Not Agile

I’m hearing and seeing the word ‘agile’ more and more around the office. It comes up in hallway conversations and management presentations. Managers have gotten the message and want us to be more agile. That’s great, right? So I ask them what it means to be more agile and the answer I get is rather vague.

It appears to come down to doing more frequent software releases where each release includes incremental enhancements. I don’t hear anything about changing the underlying development process, currently waterfall for most parts of the IT department. Is that all it takes to be ‘agile’? Just release more often?

And so it begins…

This is frequently how the agile conversation starts in big companies. Senior managers decide to be more agile in their approach to software development. They define the word agile however they choose. Their choices are usually founded on protecting much of the status quo and keeping changes to a minimum. Their goal is to improve, not reengineer.

The end result is often smaller and shorter waterfall projects. Granted, this approach reduces risk, which increases with time. So if risk reduction is the primary goal, the technique makes sense — but it’s not agile software development. It’s not even a first step toward using real agile development.

This is how agile approaches using the techniques of Scrum, Kanban, XP and/or Lean get a bad rap. Any software development approach can be called agile. It’s simply a label. Take any development process, make a few tweaks to address perceived shortcomings, and your team is agile — well, at least it’s more agile than it was.

Waterfall in disguise…

However, nothing changes fundamentally. The teams still produce lengthy business requirements documentation. They continue to generate functional and technical specifications. They leave their change prevention — sorry, change control — process in place. They leave the testers out of the loop until the final development stage.

They may achieve some incremental gains as a result of reducing risk. The success rate of projects may increase (depending upon how one defines success). But important questions remain…

• Have the relationships between technical and business people improved?
• Are the stakeholders and user representatives actively engaged with the development team?
• Are lead times shorter for new feature requests?
• Is the quality of the software better?
• Are the software users/buyers delighted?

Take my advice. Stop focusing on the process. Start focusing on the users.

photo credit: Mykl Roventine via photopin cc

Don’t Just Prioritize User Needs, Prioritize the Process Too

Many software development teams go to great lengths to prioritize requirements, features or user stories. (I hope your team does.) It’s a valuable exercise if people take the time to truly evaluate the importance of each request they make or receive.

Do you want to improve your software development process? Apply the same logic to the various elements of your process — prioritize them. Not every aspect of the software development process is equally important. Nor should every artifact be used on every project.

Here are three categories I’ll use to prioritize process elements:

• Strategic
• Important
• Non-essential

As for the elements of the process to prioritize, that’s pretty much up to you to decide. Here are some ideas to get you started:

• Product vision
• Project goals
• High-level software requirements or user epic backlog
• Detailed software requirements or user story backlog
• Specifications and other documentation
• Process diagrams
• Architecture diagrams
• Source code
• Test scripts/code
• Build scripts
• Deployment scripts
• Defect tracking
• Change management
• Status meetings
• Metrics

Now think about this.

What elements of your software development process are Strategic? Important? Non-essential? Here are my definitions. Feel free to re-word to your liking.

Strategic – Any part of the process that is critical to the success of the project. (If you claim that everything is strategic, go to your office. Do not pass the team room. Do not collect your paycheck!)

Strategic process elements are vital to project teams. Teams simply cannot function without them. Think long and hard about what you label strategic. Good project teams can operate with very little guidance. Poor or inexperienced teams may need much more.

Important – Important elements help teams do better. While teams can get by without them, these elements offer things like time savings or improved quality.

For example, automating the deployment process might be important to a team that does frequent deployments but not so much to one that deploys infrequently.

Non-essential – Whatever is left is non-essential. These elements are useful either to the team or to external participants but don’t add much value. I’m not equating non-essential with wasteful. (I suppose wasteful might be a fourth category but I’m hoping you’re better than that.)

For example, tracking metrics might be considered non-essential but it can be a useful tool for improving team performance.

What’s it to you?

I encourage you to go through this exercise. Start with your core team. Do it again with your stakeholders and possibly a third time with your suppliers (internal or external groups you depend upon). You won’t get the same results each time but that’s okay. You’ll develop a list of what really matters and what doesn’t.

Focus on the strategic elements. Do all of them to the best of your ability. Make sure they are complete, comprehensive and thoroughly vetted. They should be part of every project you do.

If any important element is not providing the value expected by the team, eliminate it. Do the remaining important elements well. They should be complete but not necessarily comprehensive or elegant. You might skip them for some projects.

As for the non-essential elements, consider trashing them all. You may want to keep a few around for job satisfaction or team morale reasons. There may be a few that can be improved to the point where they become important (or even strategic).

Focus on what really matters.

photo credit: jakuza via photopin cc

Software Projects Fail for the Wrong Reasons

I’d like to discuss failure — specifically, software development projects that fail. Has it ever happened to a project team you were on? If so, it was probably not for the reason you think.

Before we can examine this further, we need to agree on what constitutes failure. I’ll offer my definitions and you can add yours in the comments if you like.

What is failure?

• The project never finishes. It’s canceled before the team considers it done.
• The budget is exceeded by more than 20%. (Why 20%? It’s a number that feels like failure to me. You might use a different number.)
• The team misses a critical deadline AND ‘must have’ features are not working. (You did prioritize features, right?)
• The team delivers working software but the stakeholders and business users are unhappy with the result.
• The project just drags on. There’s no budget, timeline or definitive requirements — there’s also no definition of done.

I’m sure that anyone who has been involved in software development for more than a few years has experienced one or more of these situations. If you haven’t yet, you will– and it won’t be pretty.

Why do software projects fail?

The reasons for failing projects are as varied as the projects themselves. I don’t want to dwell on information that is available elsewhere so I’ll try to offer a different perspective.

1. It’s widely perceived that lack of management oversight and control leads to project failure. I disagree. I believe that projects often have too many managers and too many controls. The focus is on managing the process when it should be on getting stuff done.
2. Lack of people management is another widely perceived failure point. Wrong again. If the company has hired good people, they know what they need to do and how to do it. Get out of the way and let them do their jobs. Give them some running room and some time to accomplish something. (Oh — and fire the non-performers and troublemakers.)
3. Poorly defined requirements is a real problem but not for the reason you might think. The stakeholders and end users know what they want. Pay attention to them. Problems develop because we don’t spend enough time talking through what’s wanted, establishing common goals, and determining what really matters. (Lengthy requirements specifications can’t solve that problem.)
4. Contrary to popular opinion, projects don’t fail due to lack of time, money or people. They fail because expectations are not managed well. People become locked into their favorite solution or approach and are unwilling to accept a different idea. Spend more time leading and less time controlling.
5. Lack of process, governance or change control are also often cited as failure reasons. Sorry. Those are invalid reasons too. There is either too much of those things, stifling the project team, or they are being improperly applied resulting in poor decisions. Keep it simple.

Would you like to succeed more and fail less?

• Stop managing so much and start delivering results.
• People are more important than process. Respect them.
• Documentation is a tool not a result. Don’t abuse it.
• Protect relationships not ideas.
• Change is good. Be open to changing your plans.

photo credit: Ruin Raider via photopin cc

It’s Not About the ‘How’. It’s About the ‘What’.

Software development experts, myself included, get caught up in methodology battles. I like Scrum. You like waterfall. My approach is more responsive than yours. Your approach is more disciplined than mine.

But, are we losing sight of ‘what’ really matters? The approaches we follow are the ‘how’ of building software systems. My goal (and I hope yours also) is to build better software so that our respective businesses can be successful. That’s the ‘what’ — build better software for our businesses.

If you and your team are not satisfied with the results you’re getting, you need to let go of the ‘how’ and focus on the ‘what’. In other words, if you’re unhappy with your team’s results, your approach isn’t working — so change it.

• What is wrong with the software you’re delivering?
• What makes it inferior to competitive products?
• What causes it to fall short of expectations?
• What issues are business users reporting?
• What internal goals are being missed?

Once you know ‘what’ is going wrong, you can turn your attention to the development approach to understand ‘how’ these issues came to be. You may need a completely different approach or some changes to your existing one but, either way, something needs to change.

Arguing about Scrum vs. XP vs. standard waterfall vs. iterative waterfall is a semantic debate. Instead, identify the tactics within your current process that work and those that don’t. Preserve the tactics that work and eliminate the ones that don’t.

• Don’t treat anything as sacred and unchangeable.
• Don’t start changing things simply because they’re easy.
• Don’t draw conclusions without hard data to back them up.

Here’s an example of a really bad ‘improvement’ idea. (I’ve witnessed this several times over the years.) A software system is widely perceived as buggy. It’s hard to use; it crashes; etc. The proposed solution is to do more testing. If you can identify more bugs before the software ships, you’re ahead, right?

– Wrong! –

If the software is buggy, there’s a fundamental problem with your team’s approach to specifying, building and testing it. Your entire process from front to back is suspect. That elephant is too big to eat in one sitting.

Accept that the software will be buggy for a while. You can make incremental improvements but you won’t be able to fix everything in a release or two.

Get to the core issues and fix them. Until you’re willing and ready to do so, a new software development approach won’t help, whether it’s agile or not.

photo credit: dhaun via photopin cc

Agile Software Development Is Like a Home Renovation Project

Have you ever watched a home renovation show on television? I’m thinking of shows like Love It or List It and Property Brothers (both on HGTV). The specifics vary but they use the same general approach to managing renovation projects.

The work crews are given a fixed time period and a fixed budget to complete a major home improvement project. The time period is usually on the order of 3-6 weeks. The budget is usually in the tens of thousands of dollars but can go higher. The crews are required to stick to the budget and the deadline — no excuses.

Of course, unexpected issues often arise. There may be a major electrical, plumbing, or even structural issue that ends up adding substantial time and cost to the project. But, because time and cost are fixed, something that was planned for the renovation project must be reduced or omitted.

In other words, the scope has to change to meet the time and budget goals. There are two major options available:

1. A less important section of the home may be left untouched to free up funding for the more important areas; or
2. Parts of the project may be scaled back using less expensive materials and/or faster work methods.

There are often “all-nighters” near the end of the project to meet the final objectives. While, “all nighters” are generally a bad idea, they make sense when used sparingly and in times of dire need.

What does this have to do with agile software development?

I hope the answer is self-evident. Software projects always have time and budget constraints too. No one has an unlimited supply of time or money. While some software developers may argue that the software “…will be ready when it’s ready”, in business, that attitude doesn’t fly. Deadlines are often very real with severe consequences for not meeting them. As for money, once it runs out it’s game over. Go find another job.

The only aspect of software projects that can truly vary is scope. (Unless you want to let quality float and risk shipping crapware.) Agile teams make frequent decisions about what to include and what to exclude in order to meet time and budget goals.

You see, letting the project scope float is not some kind of sinister agile concept. It’s actually widely used in many kinds of projects. Even new building construction projects encounter delays and unexpected events that add time and cost. Owners may choose to absorb either but most often, they will adjust scope to keep their commitments and maintain high quality standards.

Lesson learned: Stop trying to lock down time, cost and scope at the outset of a software project. It’s a fool’s errand. It doesn’t work in physical build projects like home construction and it doesn’t work in software development either.

photo credit: pattie74_99 via photopin cc