Information System analysis, modeling & Design

A3.6 Prototyping

In prototyping, the user gets a “trial model” of the software and is allowed to critique it. User responses are used as feedback information to revise the system. This process continues until a software system meeting user satisfaction is obtained.

The following are some basic guidelines for developing a prototype:

· Work in manageable modules.

· Build prototype rapidly.

· Modify prototype in successive iterations.

· Emphasize the user interface—it should be friendly and meeting user requirements.

Kinds of Prototypes

There are various types of prototypes that you will find in software engineering. Among the various categories are the following:

Patched-up Prototype or Production Model: This prototype is functional the first time, albeit inefficiently constructed. Further enhancements can be made with time.

Non-operational or Interactive Prototype: This is a prototype that is intended to be tested, in order to obtain user feedback about the requirements of the system represented. A good example is where screens of the proposed system are designed; the user is allowed to pass through these screens, but no actual processing is done. This approach is particularly useful in user interface design (see Chapter 6).

First of Series Prototype: This is an operational prototype. Subsequent releases are intended to have identical features, but without glitches that the users may identify. This prototype is typically used as a marketing experiment: it is distributed free of charge, or for a nominal fee; users are encouraged to use it and submit their comments about the product. These comments are then used to refine the product before subsequent release.

Selected Features Prototype or Working Model: In this prototype, not all intended features of the (represented) software are included. Subsequent releases are intended to be enhancements with additional features. For this reason, it is sometimes referred to as evolutionary prototype. The initial prototype is progressively refined until an acceptable system is obtained.

Throw-away Prototype: An initial model is proposed for the sole purpose of eliciting criticism. The criticisms are then used to develop a more acceptable model, and the initial prototype is abandoned.

5.6 Prototyping

The following are some basic guidelines for developing a prototype:

· Work in manageable modules.

· Build prototype rapidly.

· Modify prototype in successive iterations.

· Emphasize the user interface — it should be friendly and meeting user requirements.

· Patched-up Prototype or Production Model:  This prototype is functional the first time, albeit inefficiently constructed. Further enhancements can be made with time.

· Non-operational or Interactive Prototype: This is a prototype that is intended to be tested, in order to obtain user feedback about the requirements of the system represented.  A good example is where screens of the proposed system are designed; the user is allowed to pass through these screens, but no actual processing is done. This approach is particularly useful in user interface design (see chapter 11).

· First of Series Prototype:  This is an operational prototype.  Subsequent releases are intended to have identical features, but without glitches that the users may identify.  This prototype is typically used as a marketing experiment: it is distributed free of charge, or for a nominal fee; users are encouraged to use it and submit their comments about the product. These comments are then used to refine the product before subsequent release.

· Selected Features Prototype or Working Model:  In this prototype, not all intended features of the (represented) software are included. Subsequent releases are intended to be enhancements with additional features. For this reason, it is sometimes referred to as evolutionary prototype. The initial prototype is progressively refined until an acceptable system is obtained.

PROTOTYPING

Prototyping is an important technique for eliciting, analysing, demonstrating and validating requirements. Analysts often complain that the business users do not know what they want, and that as a result it is difficult to define the requirements. However, it can be very difficult for anyone to envisage requirements for the future without having a sense of what is possible. It is much easier to review a suggested solution and identify where there are errors or problems. If business users are unclear about their requirements, prototypes can help them visualise the new system and provide insight into possible requirements. Using a prototype often releases the blocks to thinking, and can result in greater understanding and clarity. Prototypes also offer a way of demonstrating how the new processes or system might work and provide a concrete basis for evaluation and discussion. Agile software development approaches, such as DSDM and Scrum, use evolutionary prototyping as an integral part of their development lifecycle.

Prototyping involves building simulations of a process or system in order to review them with the users to increase understanding about the requirements. There is a range of approaches to building prototypes. They may be built using the organisation’s system development environment so that they exactly mirror the future system. Images of the screens and navigations may be built using presentation software packages such as Microsoft PowerPoint or they may be mock-ups on paper. A quick but effective form of prototyping is to use flipchart sheets, pens and packs of sticky notes and work with the users to develop paper prototypes. This will enable the users to develop screens, identify navigation paths, define the data they must input or refer to, and prepare lists of specified values that they know will apply. This approach can also be used to develop prototypes of a business process.

There is a strong link between scenarios and prototyping because scenarios can be used as the basis for developing prototypes. As well as confirming requirements, prototyping can often help the users to identify some that they had not considered previously.

Advantages and disadvantages of prototyping

Prototypes are useful for a variety of reasons including:

· to clarify any uncertainty on the part of the analysts and confirm to the user that we have understood what they asked for;

· to help the user identify new requirements as they gain an understanding of what the system will be able to do to support their jobs;

· to demonstrate the look and feel of the proposed system and elicit usability requirements;

· to validate the system requirements and identify any errors;

· to provide a means of assessing the navigation paths and system performance.

Prototyping has a number of hazards, most of which can be avoided by setting clear objectives for the prototyping exercise and managing the stakeholders’ expectations. The hazards include:

· The prototyping cycle can spin out of control with endless iterations taking place.

· If the purpose of the exercise has not been explained clearly, the users may think that when they are happy with the mock-up, the system is now complete and ready for use.

· User expectations can be raised unnecessarily by failing to mimic the final appearance of the system, or its performance; a system that is on a stand-alone machine with six dummy data records to search will be more responsive than a machine that is sharing resources with a thousand other machines on a national network, and has several million records to access. If there is likely to be a delay in the real response time, it is important that you build that into the prototype.

In an Agile software development environment, prototyping sessions are used to elicit and analyse requirements, and to construct and test working functionality. The development work is conducted iteratively, with each iteration using the concept of a timebox or sprint, typically a predefined number of weeks, within which certain functionality is delivered. During the timebox, the selected requirements for that delivery will be validated, coded, tested and released. Contingency is provided by the prioritisation of the requirements, whereby some are designated at a lower level of priority and may be postponed to a later timebox if necessary. In this approach, the tension between time and quality is resolved in favour of time but, because Agile encourages iterative development, the quality – i.e. the scope of functionality – is merely postponed, not sacrificed. The prototyping approach allows the business to receive the most critical pieces of functionality when it needs it, and the less urgent functionality will be delivered in future iterations.

What Is Agile?

Agile is a set of methods and methodologies that help your team to think more effectively, work more efficiently, and make better decisions.

These methods and methodologies address all of the areas of traditional software engineering, including project management, software design and architecture, and process improvement. Each of those methods and methodologies consists of practices that are streamlined and optimized to make them as easy as possible to adopt.

Agile is also a mindset, because the right mindset can make a big difference in how effectively a team uses the practices. This mindset helps people on a team share information with one another, so that they can make important project decisions together—instead of having a manager who makes all of those decisions alone. An agile mindset is about opening up planning, design, and process improvement to the entire team. An agile team uses practices in a way where everyone shares the same information, and each person on the team has a say in how the practices are applied.

The reality of agile for many teams that have not had as much success is quite different from its promise, and the key to that difference is often the mindset the team brings to each project. The majority of companies that build software have experimented with agile, and while many of them have found success, some teams have gotten less-than-stellar results. They’ve achieved some improvement in how they run their projects—enough to make the effort to adopt agile worth it—but they haven’t seen the substantial changes that they feel agile promised them. This is what that mindset shift is all about; “going agile” means helping the team find an effective mindset.   

But what does “mindset shift” really mean? If you’re on a software team, then what you do every day is plan, design, build, and ship software. What does “mindset” have to do with that? As it turns out, the practices you use to do your everyday work depend a lot on the attitude that you and your teammates have toward them.

Here’s an example. One of the most common agile practices that teams adopt is called the daily standup, a meeting during which team members talk about what they’re working on and their challenges. The meeting is kept short by making everyone stand for the duration. Many teams have had a lot of success adding a daily standup to their projects.

So imagine that a project manager is just learning about agile, and wants to add the daily standup to his project. To his surprise, not everyone on his team is as excited about this new practice as he is. One of his developers is angry that he’s even suggesting that they add a new meeting and seems to feel insulted by the idea of attending a meeting every day where he’s asked prying questions about his day-to-day work.

Figure 1-1. A project manager who wants to have the team start holding a daily standup is surprised that not everyone is immediately on board with it.

So what’s going on here? Is the developer being irrational? Is the project manager being too demanding? Why is this simple, well-accepted practice causing a conflict?

Both the project manager and the developer have different—and valid—points of view. One of this project manager’s biggest challenges is that he puts a lot of effort into planning the project, but when the team runs into problems building the software they deviate from the plan. He has to work very hard to stay on top of everyone on the team, so that he can make adjustments to the plan and help them deal with their problems.

The developer, on the other hand, feels like he’s interrupted several times a day for meetings, which makes it very hard for him to get his work done. He already knows what he needs to do to get his own code built, and he doesn’t need another person nagging him about plans and changes. He just wants to be left alone to code, and the last thing he wants is yet another meeting.

Figure 1-2. Both people seem to have a valid reason for their attitude toward the daily standup meeting. What effect will this have on the project?

Now imagine that the project manager is able to get everyone—even this reluctant developer—to start attending a daily standup meeting. What will that meeting look like? The project manager will be thinking mainly about how people are deviating from his plan, so he’ll concentrate on getting status from each person. The developer, on the other hand, wants the meeting to end as quickly as possible, so he’ll tune out everyone else while he’s waiting to give his update, then say as little as possible when it’s his turn, and hope that the whole thing ends quickly.

Let’s be clear: this is how many daily standups are run, and while it’s not optimal, a daily standup that’s run this way will still produce results. The project manager will find out about problems with his plan, and the developer will benefit in the long run because those problems that do affect him can be taken care of sooner rather than later—and the whole practice generally saves the team more time and effort than it costs. That makes it worth doing.

But what would happen if the developer and the project manager had a different mindset? What if each person on the team approached the daily standup with an entirely different attitude?

For example, what would happen if the project manager felt like everyone on the team worked together to plan the project? Then the project manager would genuinely listen to each team member, not just to find out how they’ve deviated from his plan, but to understand how the plan that everyone on the team worked together to create might need to change. Instead of dictating a plan, handing it to the team, and measuring how well the team is following it, he’s now working with the team to figure out the best way to approach the project—and the daily standup becomes a way to work together to make sure everyone is doing the most effective thing possible at any given time. As the facts of the project change each day, the team uses the daily standup to work together to make the most effective decisions they can. And because the team meets every day, changes that they discover in the meeting can be put into effect immediately so they don’t waste a lot of time and effort going down the wrong path.

And what if the developer felt like this meeting wasn’t just about giving status, but about understanding how the project is going, and coming together every day to find ways that everyone can work better? Then the daily standup becomes important to him. A good developer almost always has opinions not just about his own code, but about the whole direction of the project. The daily standup becomes his way to make sure that the project is run in a sensible, efficient way—and he knows that in the long run that will make his job of coding more rewarding, because the rest of the project is being run well. And he knows that when he brings up a problem with the plan during the meeting, everyone will listen, and the project will run better because of it.

Figure 1-3. When every person on the team feels like they have an equal hand in planning and running the project, the daily standup becomes more valuable—and much more effective.

In other words, if people on the team are in the mindset that the daily standup is simply a status meeting that must be endured, it’s still worth doing, but it’s only slightly more effective than a traditional status meeting. But if everyone on the team shares the mindset that the daily standup is their way of making sure that everyone is on track, they’re all working toward the same goal, and they all have a say in how the project is run, it becomes much more effective—and also more satisfying. The developer has the attitude that this meeting helps him and his team in the long run. The project manager has the attitude that when each person on the team can contribute to the plan, the project gets better results. And when everyone shares these attitudes, the daily standup helps them all work faster, communicate more directly, and get things done more easily.

This is just one small example of how the mindset and attitude of the team have a big effect on how well they’ll adopt agile practices. An important goal of this book is to help you understand how your own team’s mindset affects your projects and your own agile adoption. By exploring Scrum, XP, Lean, and Kanban, you will learn both sides of the agile coin—principles and practices—and how they come together to help you build better software.

Understanding Agile Values

We do not act rightly because we have virtue or excellence, but we rather have those because we have acted rightly. We are what we repeatedly do. Excellence, then, is not an act but a habit.

Aristotle, Nichomachean Ethics

Agile, as a movement, is different from any approach to software development that came before it, because it started with ideas, values, and principles that embody a mindset. It’s through the lens of these ideas that you can begin to become more agile as a practitioner, and more valuable as a member of your project team.

The agile movement is revolutionizing the world of software development. Teams that adopt agile have consistently reported improvements—sometimes huge leaps—in their ability to build great software. Teams that successfully adopt agile build better, higher quality software products, and they do it faster than before.

Figure 2-1. The waterfall model.

As they talked, Bruce and Dan confirmed a few things that reinforced her opinion. Just as Joanna suspected, there were a lot of specifications sitting in large binders and gathering dust on shelves all across the company. Somehow, everyone expected a group of users, managers, and executives to create a perfect requirements specification. In real life, the spec had a nasty habit of changing so that it would be inaccurate by the time the team got their hands on it, and would progress to being disastrously wrong by the time the team finished building the software. Bruce, Dan, and a lot of other people at the company knew that it was unreasonable to expect the perfect spec, but they still ran their projects as if it were possible.

No Silver Bullet

KEY POINTS

Agile to the Rescue! (Right?)

It didn’t go nearly as smoothly as they’d expected.

Agile to the Rescue! (Right?)

You probably know what a waterfall process feels like, even if you’re just learning the term “waterfall” for the first time. Joanna, Bruce, and Dan do, too. Before jumping into planning the jukebox project, they talked about how waterfall processes had caused problems for their teams in the past.

On their last project, Bruce and Dan worked with Tom, a customer account manager at the company, who spent a lot of time on the road helping customers at arcades, casinos, bars, and restaurants install and use their products. The three of them spent the first few weeks of the project building up a specification for the new slot machine. Tom was only in the office half the time, which gave Bruce and Dan time to start designing the software and planning the architecture. Once all three of them had agreed on the requirements, they called a big meeting with the CEO and senior managers of the company to review the requirements, make necessary changes, and get approval to start building.

At that point, Tom went back out on the road, leaving the work up to Bruce and Dan. They broke the project down into tasks, dividing them up among the team, and had everyone start building the software. When the team was almost done building the software, Tom gathered a group of business users, project managers, and executives into a big conference room to do a demo of the nearly complete Slot-o-matic Weekend Warrior software.

It didn’t go nearly as smoothly as they’d expected.

At the demo, they had an awkward conversation where the CEO asked, “The software looks great, but wasn’t it supposed have a video poker mode?” That was an unfortunate discovery. Apparently, the CEO was under the impression that they were working on software that could be deployed to either the slot machine hardware or the video poker hardware. There had been a lot of discussion of this between the senior managers, the board, and the owners of their two biggest customers. Too bad nobody had bothered to tell the team.

The worst part about it was that if Dan had known about this earlier in the project, it wouldn’t have been difficult to change direction. But now, they had to rip out enormous amounts of code they’d already written, and replace it with code retrofitted from the video poker project. They spent weeks troubleshooting weird bugs that were caused by integration problems. Dan spent many late nights complaining to Bruce that this was 100% predictable, and that this almost always happens when code built for one job is hastily repurposed to do something else. Now he’s going to be stuck with a tangled mess of spaghetti code. It’s going to be difficult to maintain this codebase, and the team is frustrated because it clearly didn’t have to be this way.

And this wasn’t just a problem for Dan and Bruce. The project manager for that project was so unhappy that he left the company. He had trusted the team’s estimates and status, which were completely destroyed by the video poker change. The team had no idea that they would have to deal with the unexpected hardware change, but that didn’t make the project manager’s life any easier. Even though the facts on the ground had changed, the deadline was set in stone. By the time the project ended, the plan was out of date and basically useless, but the project manager was being held accountable for it anyway. After being raked over the coals by the senior managers in the company, all he could say in his defense is that his team didn’t give good numbers to start with. Pretty soon, he left the company for another job—and Joanna was hired shortly after that.

Tom may have been the most frustrated of the group, because he was the one who had to face the customers when they ran into problems. Their biggest customer for this product was the Little Rock, a casino in Las Vegas that wanted to customize all of their slot machines with themes to match their reproductions of cities in Arkansas. The customer had requested this new feature so they could change games between shifts without having to move kiosks around. Their engineers kept running into bugs left in the software by Bruce’s team, which meant that Tom and Dan had to spend weeks on the phone with the engineers coming up with patches and workarounds. The Little Rock didn’t cancel any contracts, but their next big order was with a competitor, and it wasn’t a secret that the CEO and managers blamed the Slot-o-matic Weekend Warrior project for the loss of business.

In the end, everyone knew that the project went wrong. And each person had a pretty good idea of how it was somebody else’s fault. But nobody seemed to have any idea how to fix these types of recurring problems. And the software that they’d delivered was still a mess.

Adding Agile Makes a Difference

“Better-Than-Not-Doing-It” Results

But have they really become an agile team?

A Fractured Perspective

How a Fractured Perspective Causes Project Problems

Figure 2-2. Individual team members tend to add agile practices in areas of the project that they’re already good at, so the team only improves in those areas—and that’s why a fractured perspective leads to better-than-not-doing-it results.

How does a team get past this problem?

KEY POINTS

· Better communication helps a team manage change better.

· Many teams try “going agile” by adopting great agile practices that improve on what they already do well today.

The Agile Manifesto Helps Teams See the Purpose Behind Each Practice

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

· That is, while there is value in the items on the right, we value the items on the left more.

Individuals and Interactions Over Processes and Tools

Working Software Over Comprehensive Documentation

Customer Collaboration Over Contract Negotiation

Responding to Change Over Following a Plan

Figure 2-3. Agile teams often use task boards to show tasks and track progress. They’ll write tasks or user stories on index cards, and move them across the board as they progress. Many teams also draw charts on their task boards to help them track progress.

Principles Over Practices

KEY POINTS

· The Agile Manifesto contains common values and ideas that lead to effective teams.

· Working software means software that delivers value to the company.

· “Customer collaboration over contract negotiation” means treating everyone like they’re on the same team.

Understanding the Elephant

Figure 2-4. The agile “elephant” is greater than the sum of its practices.

· Individuals and interactions over processes and tools

Methodologies Help You Get It All in Place at Once

Figure 2-5. Scrum, XP, and Lean all have the agile values at their core, and share some values, ideas, and practices with each other.

Where to Start with a New Methodology

There’s a solution: the 12 principles that go hand-in-hand with the values of the Agile Manifesto. You’ll learn about them in Chapter 3.

KEY POINTS

FREQUENTLY ASKED QUESTIONS

When the Agile Manifesto talks about not having comprehensive documentation, does that mean we don’t have to write anything down?

Are you sure? I’ve definitely heard that agile means not writing anything down or doing any planning, and instead jumping straight into programming. Isn’t that more efficient?

To a developer looking in from the outside, however, this may actually look a lot like jumping straight into the project without planning. When the team only spends a single day at the beginning of the 30-day iteration planning, it means that on the second day the team can start programming (if that’s what makes the most sense to them). So that often looks like they’re barely doing any planning, even though it’s actually a lot of planning when the effort-hours are added up.

Doesn’t that mean that agile is only for very experienced developers who are good at planning?

Can I have the developers on the team go agile, but leave the rest of the team (testers, business analysts, UX designers, project managers, etc.) alone?

If I’m not using Scrum, XP, Lean, or Kanban, does that mean my team isn’t agile?

Absolutely not. There are many agile methodologies—we’re concentrating on a few here, because we’re using them to teach you about the ideas behind agile. But more importantly, one goal of this book is to help you answer the question, “What does ‘agile’ really mean?” Throughout the rest of this book, you’ll learn about the values and practices of different methodologies and methods, and through them you’ll learn what it means to be agile—and how such different methodologies and methods can all be agile, even if they don’t resemble each other.

THINGS YOU CAN DO TODAY

· Write down a list of all of the practices that you and your team use when you build software. They may be things like writing a specification, or checking your code into a version control system, or using a Gantt chart to document your project plan, or holding a daily standup meeting.

· Ask someone else on your team to write down her own list of all of the practices that you and your team use. Compare your lists. What practices are on one list but not the other? Have a discussion about that practice. Can you find a difference in perspective between the two of you?

WHERE YOU CAN LEARN MORE

COACHING TIPS

5. Businesspeople and developers must work​ together daily throughout the project.

7. Working software is the primary measure of progress.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

If I had asked people what they wanted, they would have said faster horses.

Henry Ford

There’s no single recipe that results in perfect software every time. Agile teams recognize this. Instead, they have ideas and ground rules that help to guide teams to make the right choices and avoid problems—or deal with those problems when they inevitably happen.

“Do As I Say, Not As I Said”

Delivering the Project

Principle #1: Our Highest Priority Is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software.

Project teams work in the real world, and in the real world things never go perfectly. Even a team that does a brilliant job of gathering and writing down requirements will miss things, because it’s impossible to completely and perfectly capture the requirements for any system. That’s not to say that teams shouldn’t try, and agile methodologies are based on some great practices for communicating and writing down requirements. But the fact is that until customers get their hands on working software, they have a hard time envisioning exactly how the software will work.

Principle #2: Welcome Changing Requirements, Even Late In Development. Agile Processes Harness Change for the Customer’s Competitive Advantage.

Why are changes in a project emotionally charged? Understanding that is a key to this principle. Think back to the last time you were working on a project and found out that you needed to change what you were building. How did it feel? Until that moment, you thought the project was going well. You probably made a lot of decisions: how to structure your work, what you were building, and what you promised to deliver to your customers. Now someone outside of the project is telling you that some of that planning and work was wrong—that you were wrong.

· We learn from the changes. This is the most effective way for a team to grow and get better at building software together.

Principle #3: Deliver Working Software Frequently, from a Couple of Weeks to a Couple of Months, with a Preference to the Shorter Timescale.

Andrew: I’m not familiar with military systems—what’s a command-and-control system?

Command-and-control project management is similar to military command-and-control:

Figure 3-1. The team uses iteration to deliver working software frequently, adding new features with each release. 

This is where agile starts to become very attractive to a traditional command-and-control project manager. A command-and-control project manager wants to control the deadline. Timeboxed iterations give the project manager that control. This also solves one of the project manager’s biggest challenges: dealing with changes that come in very late in the project. One of the most difficult parts of a traditional project manager’s job is monitoring for changes. The daily reviews and iteration retrospectives let the project manager enlist the whole team as eyes and ears to spot those changes much earlier, before they can cause more serious problems with the project.

Better Project Delivery for the Ebook Reader Project

Figure 3-2. At the beginning of each iteration, the team chooses features from the backlog to build.

KEY POINTS

Communicating and Working Together

Principle #4: The Most Efficient and Effective Method of Conveying Information To and Within a Development Team Is Face-To-Face Conversation.

Instead, the most efficient way for the team to communicate the important ideas needed for the project is to get everyone thinking the same way. That way, each person can handle every decision as it comes. When a group of people look at the world the same way, and communicate about both positive and negative ideas openly, they end up with a shared perspective. When a change comes along that requires rethinking, the team members don’t have to explain as much to each other.

Principle #5: Businesspeople and Developers Must Work Together Daily Throughout the Project.

Agile teams sometimes forget that the businesspeople they work with have day jobs. This leads to a natural disconnect between software teams and the businesspeople they build software for. 

Figure 3-4. Some features in the backlog are more valuable to the company than others. The team has to balance the value (how much a feature is worth) against the cost (how much work it takes to build) when they determine which ones to include in each iteration.

Principle #6: Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need, and Trust Them to Get the Job Done.

· Basing business analysts’ performance reviews on the amount of documentation they produce (rather than the amount of knowledge they’ve shared with the team).

Better Communication for the Ebook Reader Project

Figure 3-5. When the team relies more on face-to-face communication, and only uses the minimal amount of documentation needed to build the project, it’s easier for everyone to stay in sync with each other.

KEY POINTS

· Agile teams communicate most effectively when they focus on face-to-face conversation and rely on the minimum amount of documentation necessary for the project (Principle #4).

Project Execution—Moving the Project Along

Principle #7: Working Software Is the Primary Measure of Progress.

Figure 3-6. Working software is better than progress reports for giving everyone the latest update on the project’s status, because it’s the most effective way for the team to communicate what they’ve accomplished.

Principle #8: Agile Processes Promote Sustainable Development. The Sponsors, Developers, and Users Should Be Able to Maintain a Constant Pace Indefinitely.

It’s a lot faster in the long run to avoid a bug now than it is to fix it later. And it’s a lot easier to maintain code that’s well designed, because well-designed code is built in a way that’s easy to extend.

A Better Working Environment for the Ebook Reader Project Team

Let’s imagine that our ereader team has applied these new principles, and now they’re a well-oiled software-producing machine. They’re iterating and delivering working software regularly, and they’re constantly adjusting to make sure they’re always building the most valuable software they can. They’re communicating well, and only documenting what they need to document. They’re using great design practices and building a maintainable codebase. And they’re doing it all without having to work overtime. Our team has gone agile!

KEY POINTS

· Teams are most productive when they work at a sustainable pace and avoid heroics, shortcuts, and overtime (Principle #8).

· Software that’s designed and implemented well is fastest to deliver because it’s easiest to change (Principle #9).

Constantly Improving the Project and the Team

One of the most basic design principles—not just in software, but in all of engineering—is KISS (“keep it simple, stupid”). An agile team lives by this principle in the way they plan the project, build the software, and run the team.

Principle #10: Simplicity—the Art of Maximizing the Amount of Work Not Done—Is Essential.

Principle #12: At Regular Intervals, the Team Reflects on How to Become More Effective, Then Tunes and Adjusts Its Behavior Accordingly.

KEY POINTS

· Agile teams keep their solutions as simple as possible by avoiding building unnecessary features or overly complex software (Principle #10).

The Agile Project: Bringing All the Principles Together

FREQUENTLY ASKED QUESTIONS

I’m a “rock star” developer, and I just need people to get out of the way so I can build great software! Why do I need to think about things like task boards and burndown charts?

I’m a project manager, and I’m still not clear on how I fit into an agile team. What’s my role in all of this?

If you’re a project manager, it’s likely that you fall into one of three traditional project management roles:

Wait a minute. If the whole team plans together, then does that mean nobody’s in charge? That would be really impractical. How are decisions made?

THINGS YOU CAN DO TODAY

WHERE YOU CAN LEARN MORE

Here are resources to help you learn more about the ideas in this chapter:

· You can learn more about challenges teams face in going agile, and how they can overcome them, in Succeeding with Agile, by Mike Cohn (Addison-Wesley, 2009).

· You can learn more about getting past the command-and-control mindset in Coaching Agile Teams, by Lyssa Adkins (Addison-Wesley, 2010). 

COACHING TIPS

Tips for agile coaches helping their team to work with the ideas in this chapter:

References

Foster, Elvis C. (2014) Software Engineering: A Methodical Approach. Apress.

Foster, E.; Godbole, S. (2014) Database Systems.

Paul, Debra; Cadle, J. and Yeates, D. (2014) Business Analysis – Third Edition.