Category Archives: Extreme Programming

We’re not good enough – and that’s okay (Norwegian)

This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October.

Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til.

Vi har lært en del ting om hva som i teorien skal være løsning:

  • Clean code skal være løsningen. Dersom vi bare hadde brukt de riktige patterns, prinsipper og teknikker sÃ¥ hadde alt vært bra.
  • Software craftsmanship – eller hÃ¥ndverksÃ¥nd – skal være løsningen. Dersom vi bare hever lista for oss selv som fagfolk sÃ¥ hadde alt vært bra.
  • Funksjonell kontroll skal være løsningen. Hadde vil bare hatt en dyktig produkteier (fagfolk!) og en ryddig produktkø sÃ¥ hadde alt vært bra.

Men det er jo ikke sant.

  • Selv om alle er enige om a koden skal være god, sÃ¥ er vi veldig uenige om hva som er god kode. Spesielt koden andre skriver. Mange team har stille eller støyende uenigheter om koden skal være slik eller sÃ¥nn.
  • Jeg programmerer som en adspredelse i stedet for Ã¥ spille data eller se pÃ¥ serier. Det er veldig praktisk for meg at det Ã¥ trene pÃ¥ faget er verdsatt; MEN DET BURDE IKKE VÆRE EN FORVENTNING for at man skal kunne være stolt av jobben.
  • Og det vi driver med er ofte ikke sÃ¥ viktig for den store verden. Det er ikke verdt Ã¥ tape familietid eller søvn over. Noen ganger kan det være direkte skadelig. Vi skal ta oss i akt og huske at et av de eldste informasjonssystemene var det Dehomag leverte til Nazistene for Ã¥ drive konsentrasjonsleire. Oppgaver som er verdt Ã¥ gjøre følger ikke fra funksjonelle beskrivelser

Så hva kan man gjøre, da?

  • For Ã¥ fÃ¥ en kodebase med mindre hindringer er det viktigste skrittet at utviklerne snakker mer om koden og at man lærer seg Ã¥ være ydmyk. Spesielt vi mannfolka mÃ¥ bli flinkere til Ã¥ si “jeg tok feil”. Og det krever trening! Og parprogrammering funker!
  • Vi mÃ¥ lære oss Ã¥ begrense oss selv. Den viktigste mÃ¥ten jeg har fÃ¥tt opp farten pÃ¥ er ved Ã¥ gÃ¥ saktere – spesifikt ved at hele teamet fokuserer pÃ¥ ÉN oppgave om gangen. Dette kalles gjerne swarming. Som team: Bli ferdig med én ting og gÃ¥ til neste i stedet for Ã¥ starte pÃ¥ enda flere ting.
  • Til slutt mÃ¥ vi lære oss Ã¥ si stopp. De fleste organisasjoner mangler mekanismer for Ã¥ oppdage og handle dersom man driver med tull. De fleste personer har problemer med Ã¥ innse at man løper et tapende løp. Det aller viktigste er pÃ¥ det personlige plan: Ikke forbli et sted der kulturen er dÃ¥rlig og hvor folk ikke er snille med hverandre.

Jeg vet ikke hva som skal til for Ã¥ lykkes, men jeg vet noen mÃ¥ter vi alltid tabber oss ut pÃ¥: Jeg vet det er vanskelig Ã¥ si “jeg tok feil”; jeg vet det er vanskelig Ã¥ si “la oss bli ferdig med dette før vi starter pÃ¥ noe nytt”; jeg vet det er vanskelig Ã¥ si “nok er nok”. Disse tingene er hva jeg vil bli flinkere til.

Posted in Extreme Programming, Norsk, Pair programming, Software Development | Leave a comment

Forget about Clean Code, let’s embrace Compassionate Code

When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others.

Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies. I often leave the office 1-2 hours later than my co-workers after polishing some piece of ultimately meaningless code. This is time I don’t spend with my family. Because I’ve learned to care about Clean Code.

Some of the most unpleasant experience in my professional life have been due to disagreements of the Clean way to write some piece of Code. I know people that I respect professionally that could have been good friends if one of us hadn’t insisted on purity of code in some situation or another.

And I’m not alone. I’ve seen teams that are at conflict with each other because of different expectations of a programmers obligations. Often fuelled by the idea of Clean Code.

As I’ve grown older, I learned to stop getting upset about “Unclean” Code. In any real world code base there will be an uncountable number of unfortunate quirks, odd and ends. This is okay. Things are the way they are because they got that way. People did what they did because of reasons. Those reasons are valid, whether it was because the surrounding needs changed, because the developer had insufficient experience, because they wanted to go home to their family instead of sitting late in the office or if they just had a difference in opinion on what’s good code.

I sometimes train teams in TDD, incremental design, refactoring and pair programming. I almost always have to spend a lot of time helping the team bridge their disagreements in a more constructive way. And often the ones who have read Clean Code are the most susceptible to this sort of conflicts.

Why do I bring this up now? Because the reason that the idea of Clean Code is unhelpful as a guiding principle came in stark relief last weekend. The reason is simply this: We get led astray when we follow a principle or a rule without reflecting on what it does to ourselves and others. Robert (Uncle Bob) Martin is the author of the Clean Code book and a prominent developer trainer. He often writes on obligations, the oath to defend and preserve the honor of the profession, and shames excuses for not doing TDD. For a long time, there has been a nagging feeling at the back of my head about this language of “honor”, “obligation” and “professionalism”. But I enjoy test-driven development, and I have experienced it as a more fun way to develop. I believe that developers should reject illegal orders. I agree with Uncle Bob on all of these specific points.

Only when he writes something that I strongly disagree with, does the hunch about Clean Code became clear. The last days on Twitter we watched Uncle Bob implicitly decry the violation of Godwin’s law rather than the internment of thousand children under conditions that Amnesty International compare with torture. In the following days, Uncle Bob fought back against his critics also stressing that he thinks the situation is horrible, “but…” not as important as “unhonorably” comparing others to Nazis. I think his priorities are horribly wrong. I responded “In light of @unclebobmartin’s recent tweets, ideas like Clean Code have started creating a bad taste in my mouth. Let’s just say “code”, eh? I’m officially instituting “dirty code Monday’s” to remember to question dogma, tribalism and things-before-people mentality.” Bob asked me to explain “why you decided to lead a boycott against the concept of Clean Code”. Thus this blog post.

I deeply disagree with his stance on this political issue. I respect that some people value rules and principles higher than individual fates. I do not value rules for themselves. Bringing this back to code: I don’t believe we should use TDD because it’s a professional obligation. Instead I use TDD when it makes my work more enjoyable. I don’t think we should refactor our code because it violates a SOLID-principle. Instead I sometimes reach to a principle to understand why some piece of code is hard to change or understand. I don’t want to shame people for writing Unclean Code. Instead I believe in having an honest dialog among equals about how we want our code to look. I don’t believe that professionalism should compel us to introduce tests for all untested code. Instead I believe we should prioritize which deficiencies we fix and which code monsters we allow to live out their lives in their part of the code base.

I want to accept my unclean code as battle scars to be proud of and to be humble about, not as failings to be ashamed of.

My friend Thorbjørn Sigberg writes If your agile transformation has only one goal, it should be “Do less boring stuff”. When Clean Code becomes a source of less boring work, I’m for it. When it becomes a source of frustration and guilt, I’m against it.

For me, the ideas of Extreme Programming that bring the greatest joy to my professional life and that of my team are ideas about the whole team, about pair programming and about focusing on the users. Uncle Bob acknowledges these elements of the programming practice, but hardly ever talk about how to do it well. I don’t agree with these priorities.

As Uncle Bob nominated me as leader of “the boycott of clean code”, I guess I should try to end with something profound. How about this: Your most valuable skill is to know what’s important. Code is not important. Principles are not important. Rules are not important. People are important. That means your users, your team, your family, yourself. To quote Joshua Kerievsky’s Modern Agile: Make people Awesome. Clean Code may help or hurt that goal. Learn to see the difference.

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

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