Category Archives: Extreme Programming

The key is empowering the people who do the work

I was humbled and encouraged to learn that I was nominated for Nordic Startup Awards category of Developer Hero for my contributions to the developer community. You can vote for me or one of the other great candidates here.

For the last ten years, I have felt that the main pain points of the software development world could be fixed by empowering and inspiring those who do the work. From my perspective, I have focused on the developers.

If you are a developer working on a project, both you and the people around you will benefit greatly if you learn new things and share what you know about the problem your project is trying to solve, about the technologies you use and about the way you’re working.

Ideas like pair programming to spread the knowledge, simple design to make it possible to understand the whole solution and collaborative product backlog planning to understand the problem can help you do this.

This was the inspiration behind me starting up Oslo Extreme Programming meetup in 2004. We have hosted about 100 meetups over the years.

But even beyond your project, if you can share and learn from others in you community, we will grow even further. I have long been a fan of the lightning talk format. Most of the smart experience is in the heads of those who don’t often give talks, who don’t have a lot of time to prepare a long talk and who perhaps only feel they have one or two things to share.

If you are a human being, you know something that can inspire someone else. All you need is to have the courage to try, the patience to structure your ideas and the discipline to practice your talk.

I am proud to have witnessed some of the first talks given by some of the speakers who inspire me today, such as Christin Gorman, Karianne Berg, Henning Spjelkavik and Filip Van Laernen.

This was the inspiration behind me and others starting the Smidig (Agile in Norwegian) conference in 2007. Since 2011, I have handed over the organizing baton to others and I am happy to see that the conference is still thriving and that our original vision is still a helpful idea behind the conference. Over the years, over 500 talks have been given at the Smidig conference, many by first time speakers.

As I saw the Smidig conference in competent hands, I looked around for other areas to contribute. Fellow Developer Hero nominee Simen Sommerfelt convinced me to join the board on the Norwegian Computing Association. The organization has a 60 year history and the people who are involved with the organization possess a well of knowledge. However, the competition from meetup and other communities threaten to siphon away the vitality of the organization.

If you care about a professional field, you can step up and help others in that field find their voice. If you know the people who are worth listening to inside a field, pulling together an event where they can share their knowledge is surprisingly simple. You can use meetup.com to organize a group or you can get help from an organization like the Norwegian Computing Association.

I have been helping events happen in Norwegian Computing Association and I hope to be doing this even more in the future. Together with a great team of organizers, I helped organize the Software conference the last few years. This year, we received recognition as the Event of the year in the Norwegian Computing Association, an achievement I’m very proud of.

As I have moved from event organizer to inspiring other event organizers, my own Oslo XP meetup has fallen off the list of things I’m able to attend to. If you are looking for a place where you can contribute to the community, I would love for someone to step up as organizer for a while.

I have been privileged to be able to watch what happens when developers care about their project, share their knowledge and take responsibility for their professional community. When I see the experience and the result of people caring, I also realize that this goes beyond just the sphere of software professional.

The Norwegian government is spending billions of kroner each year on software projects. Recently, there has been a lot of attention on many of these projects that have very little to show for their investment. I believe that this waste comes from projects being run without respecting the knowledge that the developer community possesses and the professional talent that is available.

Recently, Geir Amsjø has been able to gather together a loose group of like minded people who have been contributing in the public debate on public sector IT spending. We hope that this work can affect the very way money is being allocated to these huge and important projects.

By caring about your profession in your project, your community and the world at large, you can make a difference. Enormous resources are being consumed to build IT systems around the world. Only when the people building the system care about their craft and are being listened to can this investment truly pay off.

Posted in English, Extreme Programming, Non-technical, Software Development | Leave a comment

Planning software development with a time machine

I have an amazing time machine that lets me think better about projects. This is part 3 in a series of blog posts exploring the use of a time machine.

In order to get a handle on how to build a feature for your next iteration, take a trip with your time machine to the future to watch how the feature will be demonstrated.

It’s often hard for developers to focus on exactly what tasks needs to be performed in order to build a new feature. Instead, we often end up breaking a feature down into nerdy and unfocused tasks such as “create a new table in the database”. Yawn!

Instead, form small groups of 2-3 team members, each working on one new feature at the time. The teams will write down how they would demonstrate that this feature was complete and actually working. Then each group will stand up and actually give the demo, indicating features in a system that’s not yet built.

A typical imagined demo goes something like this:

  1. “Welcome to this milestone of the development of project X. We are very excited to show you a lot of progress this week. I will now show you the exciting new … feature.
  2. “You can access the feature by starting the product and selecting X from the menu. As you can see (indicating to a black screen), you will be given a list of options to X, Y or Z. For the purposes of this demo, I will select X
  3. “….
  4. “This concludes creating a new X. We will now demonstrate how we can see that the X has been created…
  5. “As you can see, the new feature X helps user Y fulfill goal Z. I hope you are as excited about seeing actual uses start to use it as I am.
  6. “Thank you!” (applause)

While planning and giving a demo, a team often starts asking questions like “but where will we get information about X”, “how can we display Y in a sensible way” etc. These are exactly the kind of questions needed in order to plan the work ahead.

Seeing a demo from the future allows the work to be more focused on the goal and helps the team uncover hidden assumptions and missing information.

PS: I want to give kudos to my colleague Lars who has given one of the most amazing imagined demos I’ve ever seen!

Posted in English, Extreme Programming | Leave a comment

Pair programming with Sankalpa

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others.

When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa. In this session, we achieved something that we would be helpless to do alone.

The task Sankalpa and I was working on was to include information from a calendar in Confluence in a date picker in a web application. As we sat down, I was dreading the integration part. Integration is often dreadful. More than anything, I wanted to hide from the problem. But with Sankalpa sitting next to me, I didn’t feel that I could give up, so I suggested we took a look at our Confluence calendar to get started. Sankalpa was at the keyboard and he found a “calendar feed” where I hadn’t thought of looking for it.

Looking at the feed, I exclaimed “Oh, I know this – this is vcalendar”. A quick Google later and we had found a library for parsing vCalendar in JavaScript. We quickly finished the code to adapt it to our desired format and moved to the date picker.

I was at the keyboard and I had used a date picker library called jQuery datePicker before. We quickly integrated it and I proudly refreshed the page to show the calendar events in the view! But it turned out that all the functionality that depended on picking a date was now broken.

I started grumbling about how I was much more comfortable with jQuery than with AngularJs. Unfazed, Sankalpa mentioned that Manoj had gotten the date picker to work with AngularJs in an earlier project. “Hey, Manoj, where did we use this date picker?”

Having much more experience with AngularJs than me, Sankalpa integrated the code into our code base and everything was working.

All in all, I had expected this to take 2-3 times as much effort. If we had been alone, we would probably wouldn’t have the courage to start with the integration right away. If he had been alone, Sankalpa probably wouldn’t had known how to parse the vCal feed. If I had been alone, I probably would have searched the Internet for hours to find out how to make AngularJs play well with jQuery date picker.

Together, we did what neither of us could have done alone. (At least not anywhere close to this quick)

Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | 1 Comment

Estimation by stuffing things into boxes

I’ve started using an approach for software project estimation that so far is proving to be fairly transparent, quick and reliable. I’ve observed that within a reasonable degree of variation, most teams seems to complete about one “user-relevant task” per developer per calendar week.

There are so many theoretical holes in my argument that there’s no point trying to cover them all. The funny thing is that it seems to work fairly well in practice. And to the degree that it’s dirty, it’s at least quick and dirty. The only thing I will address is that one of these “user relevant tasks” is smaller than a typical application feature.

Most importantly: Most teams never get it right on the first try. Or they spend too long gold-plating everything. Or both.

This article shows an example of estimating a fictive project: The Temporary Staffing System.

The high-level scope

Let’s say that our organization has come up with the following vision:

For a temporary employment agent who wants to match candidates
to client needs, the Temporary Staffing System is an
interactive web application, which lets them register and
match candidates and positions. Unlike competing systems
this lets us share selective information with our clients.

We come up with the following flow through the application:

  1. A new company wants to hire a skilled worker for a temporary position
  2. Administrative user adds the client details to the system
  3. Administrative user adds client logins to the system
    (perhaps we also should let the clients log in with LinkedIn etc?)
  4. Client logs into the application and completes new position
    description, including skill requirements
  5. Temp agency adds a worker to the system
  6. Temp agency proposes the worker to a position registered by a client
    (in the future, the worker may register themselves!)
  7. Client gets notified of new proposals (via email)
  8. Client views status of all open positions in the system
  9. External to the system: Client interviews candidate, request further
    information and makes a decision whether to hire or not
  10. Client accepts or rejects the worker in the system
  11. As worker performs work, they register their time in the system
  12. At the end of a billing period, the system generates billing information
    to accounting system
  13. At the end of a salary period, the system generates salary information
    to the accounting system

Some of these steps may be one user story, some may be many.

The top of the backlog

We choose some of the most central parts of the scope to create the beginning of the backlog. In order to accommodate for the learning as we go along, the first draft of our backlog may look like this:

  1. Experimental create open position
  2. Experimental list positions
  3. Simplified create open position
  4. Simplified list positions
  5. Complete create open positions
  6. Complete list positions

An “experimental” version of a story is a functionality trivial version that touches all parts of the technology. In the case of these two stories, perhaps we have the application leave the logged in client as a hard coded variable. The story may only include writing some of the fields of the positions, maybe only title and description.

The Simplified version may add more complex properties, such as skills from a skill list or it may add filters to the list.

The complete version should be something we’re prepared to put in front of real users.

By revisiting a feature like this, we have the chance to get the feedback to create a good feature without gold-plating.

Continuing the backlog

We add enough of the other stories to the backlog to cover an interesting part of the scope:

  • Basic create client account
  • Complete create client account
  • Basic login admin user
  • Basic login client user
  • Complete login client user
  • Basic add worker
  • Complete add worker
  • Basic propose worker for position
  • Complete propose worker for position
  • Complete confirm worker for position
  • Basic enter timesheet (in this version temp agency enters on behalf of worker)
  • Experimental billing report
  • Basic billing report
  • Basic salary report

This functionality should be enough to have a pilot release where some clients and workers can be supported by the new system. Or we may complete the backlog with complete versions of all functionality, worker login and perhaps a polished version of a feature or two.

Adding the non-functional tasks

There are some tasks that we want to plan some extra time for. I generally find that many of these tasks are tasks that customers understand quite well:

  • Attend training on CSS (the team is rusty in design skills)
  • Basic layout and styling of web pages
  • Complete layout and styling of web pages
  • Polished layout and styling of web pages (they want it really nice)
  • Locate slowest pages and make some performance improvements
  • Deploy solution to target platform
  • Deploy demo version to wider set of stakeholders
  • Deploy pilot version
  • Exploratory test of complete flow

Planning the project

In this example project, we have five team members plus a coach/project manager on half-time. Since our team will be working in pairs, we want to work on three functional areas per week. This way, we can avoid huge merge conflicts. The team agrees to plan for five stories per week, but only three the first week, because things generally go slower. Here is the top of the completed backlog:

  • Week 1: Experimental create open position
  • Week 1: Experimental list positions
  • Week 1: Attend training on CSS
  • Week 2: Simplified create open position
  • Week 2: Simplified list positions
  • Week 2: Basic create client account
  • Week 2: Basic layout and styling of web pages
  • Week 3: Basic login client user
  • Week 3: Deploy solution to target platform
  • Week 3: Basic add worker
  • Week 3: Basic propose worker for position
  • Week 3: Basic enter timesheet (temp agency enters on behalf of worker)
  • Week 4: Experimental salary report
  • Week 4: Complete layout and styling of web pages
  • Week 4: Complete create open positions
  • Week 4: Complete list positions
  • Week 4: Deploy demo version to wider set of stakeholders
  • Week 6: Exploratory test of complete flow
  • Week 7: Deploy pilot version

Presenting the plan

Working through the list gives us a complete timeframe of just over 6 weeks for full feature set for the pilot release. To cover realities of life, we probably want to plan for at least one week of slack or even more, depending on the strength of our commitment and the consequences of being wrong.

This gives a plan indicating 7 weeks times 5 people at 40 hours per week plus a 50% project manager at 20 hours per week or a total of 1540 hours.

I generally find that after a pilot release (or even before it), things change a lot. So I don’t invest much time into planning this.

Tracking the development

The true strength of a plan like this appears when you start running the project. Each week, the team will report on which stories they completed. This allows us to adjust the plan to actual progress.

On the flip side, the weekly planning comes down the team and the customers agreeing on the definition of a story. The vagueness of “basic add worker” is by design! But the team should agree on what they mean by “experimental”, “simplified”, “basic”, “complete” and “polished”.

Conclusions

In this article, I have showed a quick and accurate way of coming up with a project forecast, complete with time and cost estimates. It’s easy to see and react to deviations from the forecast.

A few critical critical observations support this methodology:

  • I never believe a developer estimate other than “by the end of the day” or “by the end of the week”. (Don’t talk to me about hours!)
  • Estimating in hours is a silly way to get to project costs. Any hour-based estimate is always prodded and padded before magically turning into cost. Instead, estimate number of features, feature per week and cost by week.
  • Visiting a feature multiple times lowers total cost due to less gold-plating and investment of in poorly understood areas. It also improves the success of the final feature
  • The ambition of a feature (that is, how many times we will visit it) is a more reliable indication of cost than developer gut feeling

I’ve left many questions on the table, for example: What about architecture? What is meant by a “simplified” user story? How to deal with deviations from the forecast? Feel free to grill me for details in the comments to the article.

“So what will it cost?” Using this simple method to lay out your project forecast week by week, you can give a better answer next time someone asks.

Posted in English, Extreme Programming, Software Development | 1 Comment

Using pair programming to combat project waste

  • Less Overproduction (of unused functions in interface between team members)
  • Less Waiting (for the only person who knows a particular area)
  • Less Motion (as everyone gets more skilled)
  • Fewer Defects (because two pair of eyes see better than one)
  • Less Over-processing (from duplicate responsibility)
  • Less Inventory (as team works on focused set of features and tasks)
  • Less Transportation (handoffs inside a story)
  • Less Underused talent (as everyone gets to share their skills)
Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | Leave a comment

Can we learn to restrict our work to a budget?

I’ve previously talked about the idea of shifting from estimates to budgets.

The fundamental point of this article is that it’s more useful to control costs than to predict costs.

The problem of this argument is whether it’s possible to develop software in that way. How will the relationship between the developer (or supplier organization) and the customer (or the customer organization) have to change? Is this a chance we’re able to make?

In my popular style, here is a typical dialogue:

  • Customer “… So, we’re going to change the patient appointment request form to include the social security number of the user and use this field in all the relevant processes. Can it be done in two weeks?”
  • Developer “I believe so. But we probably can’t automate everything in this case.”
  • Customer “That’s all right, just do what you can within that timeframe”
  • A week passes
  • Developer “I’ve done a lot of work, but I haven’t got anything to show you yet.”
  • Customer “You’ve spend half the budget, and we’ve got nothing to show for it? That’s it, I’m pulling the plug. Throw away what you’ve done and let’s work on something else.”

Meanwhile – in another universe

  • Developer “Let me show you: I’ve got the field in the appointment request form and it’s also displayed when looking at the appointment details. I’ve tested this automatically and manually, and deployed it on the acceptance test environment.”
  • Customer “Great work so far. These are the next improvements we want (in order of importance): Make sure that non-privileged users never see the number, include the field in the invoicing process and make the input form validate the social security number. Then integrate the field in other processing as well.”
  • Developer “Sure thing. I’ll talk to the users for details.”
  • Another week passes
  • Developer “I’ve fixed the security issue by checking the user privilege before displaying the field. I’ve also included the field in the invoice process. But I didn’t have time to add the validation. Everything is tested, of course.”
  • Customer “Great! We’ve spent the budget, so we’ll stop there. The validation is actually pretty important, so I’ll considering adding a new user story to the budget for that.”

In this story the developer had to produce a minimum story before spending half the budget. This ensures that we get something when the budget runs out. The developer had to finish one expansion of the user story at a time until the budget was expended. And then stop! When the customer wanted one of these sub-features bad enough, he had to create a new user story, thus expanding the scope of the project.

Can we learn to work in this way? As a developer, can I learn to organize my work so that I have something to show for it after just half the budget? Can I learn to keep track of the time I spend so well that I know when I’m over budget? And can I have the discipline to stop once the budget has been spent? As a customer, can I learn to accept that the developer will do the best he can within my budget and accept that?

Posted in English, Extreme Programming, Software Development | Leave a comment

Micro-Scrum: A stamp-sized version of Scrum

“Show frequently what you’ve done to someone who cares”

Are you working in the way you are because it’s a good idea, or just because someone told you to do it? I increasingly hear experienced professionals at Agile conference bemoan the blind adherence to the techniques of Scrum without understanding the principles and values that make it work. I also encounter many software professionals who are overwhelmed by the amount of things that they are asked to do. The result is the questions “are we ‘Agile’?” and “should we be doing ‘Agile’ or not?”

I die a little bit inside when people say “should we do Agile or not”. The assumptions behind this question are all wrong: That there is one way to “be Agile”, that learning from Agile methods like Scrum requires that you use everything in those methods, and that there are good reasons to be “not Agile”. All of this is wrong.

To me, the most essential lesson that the Agile manifesto tries to communicate is that of Feedback. And frankly, if you’re ignoring feedback on your project, you’re stupid. There are different constraints around the feedback on different project, but essentially, delaying feedback is delaying critical learning.

The most essential manifestation of feedback in Scrum is the Sprint review, or demo. No matter if you’re calling what you do “Scrum”, “Kanban”, “Cowboy coding”, “Waterfall” (which is more like Cowboy coding than a real process) or just “the way we do stuff here”, you will get benefit from showing what you’ve done to someone who cares frequently. For some projects, “someone who cares” may be an end user, while for other projects it’s not feasible to involve end-users frequently. On some projects, “frequently” may mean every day, other projects may not be able to do more than once every month. You may even find that nobody cares about what you do. If that’s the case, surely you can find more relaxing ways of doing it.

When you are showing what you’ve done to someone who cares frequently, you can improve. You can think about how to show it better, how to have the show more accurately reflect what you’ve done, how to involve more people or people how care more and how you can do it even more frequently. Some of the techniques of Scrum may help you do that, but use whatever source of inspiration you like.

No matter if you’re excited about the word “Agile” or not, if you’re not getting feedback, you’re not only non-Agile, you’re non-smart.

Posted in English, Extreme Programming, Software Development, Technology | Leave a comment

A canonical web test

In order to smoke test web applications, I like to run-to-end smoke tests that start the web server and drives a web browser to interact with the application. Here is how this may look:

This test is in the actual war module of the project. This is what it does:

  1. Configures the application to run towards a test database
  2. Starts up the web server Jetty on an arbitrary port (port = 0) and deploys the current web application into Jetty
  3. Fires up HtmlUnit which is a simulated web browser
  4. Inserts an object into the database
  5. Navigates to the appropriate location in the application
  6. Verifies that inserted object is present on the appropriate page

This test requires org.eclipse.jetty:jetty-server, org.eclipse.jetty:jetty-webapp and org.seleniumhq.selenium:selenium-htmlunit-driver to be present in the classpath. When I use this technique, I often employ com.h2database:h2 as my database. H2 can run in-memory and so the database is fresh and empty for each test run. The test does not require you to install an application server, use some inane (sorry) Maven plugin or create any weird XML configuration. It doesn’t require that your application runs on Jetty in production or test environment – it work equally fine for Web applications that are deployed to Tomcat, JBoss or any other application server.

Please!

If you are developing a web application for any application server and you are using Maven, this trick has the potential to increase your productivity insanely. Stop what you’re doing and try it out:

  1. Add Jetty and HtmlUnit to your pom.xml
  2. Create a unit test that starts Jetty and navigates to the front page. Verify that the title is what you expect (assertEqual("My Web Application", browser.getTitle()))
  3. Try and run the test

Feel free to contact me if you run into any trouble.

Posted in English, Extreme Programming, Java, Software Development, Unit testing | Leave a comment

Only four roles

Many sources of stress on projects come from forgetting what our roles are. Scrum championed a simple set of roles with the development team, the Scrum Master, and the Product Owner. The first problem is the people affected by agile projects who fall into any of these categories, many of which are important. The second problem comes from forgetting that the only roles with authority, the Scrum Master and the Product Owner are the least important people on the whole project.

When creating something of value, the first people we care about are those who will get value from the product we create. I call these Consumers. These are the users and those who are affected by the work of the users. For a call center application, it would be the customer service representative as well as the person calling who has to wait for the service rep to look up information in the slow system.

Without caring about the Consumers, the product has no value.

The second category are those whose work goes into creating the product. It may be people who create layouts and graphics, people who develop the application, people who examine the application to make sure it performs as needed and people who train the consumers in using the application. I call these people the Creators.

Without the Creators, there will be no product.

But in order to create the product, someone usually has to put money on the line. I call this the Sponsor(s). The sponsor is the person who can really decide that, “yes, we will let five people work on this for a year”. If the Creators work for free, they are also the Sponsors. Otherwise, the sponsor is the person who signs their paycheck.

Without the Sponsor, the Creators will starve.

It’s worth noting that many Product Owners, Scrum Masters, Architects and Project Managers fall into none of these roles. The product owner is seldom an actual Consumer of the product, and in very few cases does he pay the salary of the Creators. Instead, he talks to the Consumers and helps the Creators understand what to create. In the same way, a good Scrum Master can ask good questions of the Creators that will help them avoid impediments and work better.

I call everyone who doesn’t Consume the product, Create the product or Pay for the product a Helper. When you facilitate a meeting, write a report or take the requirements from the Consumers to the Creator, you are helping. If you’re doing your job right.

The funny thing is this: Most people with authority in most organizations have Helper roles. But nothing is worse than a “Helper” you don’t need, but who insists that you do what they say.

I am a Helper, and this makes me nervous. If everybody is a Helper, nothing gets done. At best, I can make others better able to do their job. At worst, I distract from real progress.

Helpers must be humble

Posted in English, Extreme Programming, Software Development | 3 Comments

Scrum as an impediment to Agility

As I’m working with smaller and more agile projects, I’m increasingly seeing the classic way that Scrum is executed as more of an impediment to agility than a helper.

This is especially the case when it comes to the classic Sprint Planning as described in the Scrum Guide:

  • “For example, two-week Sprints have four-hour Sprint Planning Meetings”
  • In the Sprint Planning Meeting part 1: “Development Team works to forecast the functionality that will be developed during the Sprint.”
  • In the Sprint Planning Meeting part 1: “Product Owner presents ordered Product Backlog items”
  • “Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting”

I’ve seen many sprint planning meetings struggle for the same reasons again and again:

  • The user stories described by the product owner doesn’t fit the team’s way of working
  • The team dives into too many details on each user story to be able to break it down to the level required
  • The team blames the product owner for not providing enough details to the user stories
  • Most of the design discussions are considered to be over once the sprint starts
  • The forecasting/commitment to future velocity becomes a heated negotiation

If your project experienced these sorts of Sprint planning meetings, I would expect that the reaction of the project was to add meetings (“backlog grooming”), documentation and checkpoint prior to starting a new sprint. These activities would probably resulted in the product owner (team) spending less amount of time with the development team.

Scrum’s Sprint planning is assuming a situation where the product backlog is detailed for a considerable amount of time and where the ideal is that the product owner spends their time adding more details to the product backlog all the time.

The resulting projects have huge rigid backlogs describing the details for several months into the future. They communication between the users and developers is limited to the acceptance criteria that the product owner writes down before each sprint planning. They spend a considerable amount of the sprint planning the rest of the sprint. Deviations from the sprint backlog are considered problematic.

I think this is misguided. I think this is why we left waterfall in the first place.

In order for Scrum to work better, we have to abandon the idea that the product owner comes to the planning with a perfect set of stories, we have to abandon the sprint backlog detailing the work and design for several weeks and we probably should be very careful with what estimates we ask for.

Instead I would suggest the following approach to planning a sprint:

  • The product owner and the team comes into the room informed by their current understanding of the value the system can deliver
  • The product owner describes the current most important gaps in the value available to stakeholders
  • The team already knows their current trajectory and together with the product owner, they can describe “what’s the next meaningful thing we could demonstrate to closing these gaps” as a script for the next demonstration
  • The team isn’t asked to estimate their work, but the product owner, project managers and others are free to make qualified guesses based on the team’s past performance
  • Keep it short and frequent!

Scrum was developed in the time where it had to match the perception of projects that did huge batches of planning and design. In response, it does smaller batches of planning and design. But “give a man an inch and he’ll take a yard”. The smaller batches leads to frustration over lack of details and the sprints become more and more plan driven and the connection between the users and the developers more and more document-driven.

A new approach is needed.

Posted in English, Extreme Programming, Software Development | 8 Comments