posted: 02 Dec 2013
Sort of a joke and sort of isn't.
2.7M smartphones are sold every day nowadays according to @tomiahonen.
Jolla has sold 450 phones (or a little less) on its launch day on Nov 27th, some speculations and rumors tell that total preorder size is around 20K units (and at maximum could be 50K - "A typical factory batch size" mentioned by Jolla's spokes person. We also know that Finnish DNA operator starts shipping around Dec 9 and Jolla seems to be busy shipping only preordered phones during December.
Well, speculating on 1K sales a day since Dec 9 and Jolla online store to start shipments on the same day, we get the graph of "shipped to customers" smartphones market share about.
Error margin? Well, if Jolla has not 20K phones ready, but 60K (on the higher side of 50K standard batch size), then Jolla is competing for 0.072% market share by the end of 2013, not for 0.024%. Guys made lots of great work and wearing my developer's hat I can confirm that coding for Sailfish OS is a joy, but there is a long way ahead for the Jolla boat still.
posted: 04 Jun 2012
- All things cross-platform, mobile, and mobile-web. Especially Qt/QML related
- I love developing software, but also practice managing projects and technical products. My last and first successfully shipped large product had an estimated business effect of some 100-500 MEur
- One of my private apps has 40K+ downloads and another one stays in the biz apps top sellers for months already. That is supposed to illustrate that even in small projects I know what mobile users actually love and I am able to focus on shipping just the relevant bits with the high quality
- Naturally all things agile, both soft and hard parts of it up to the point of organizing conferences and speaking on test-driven development in particular environments
Location doesn't matter much as long as it is a European city large enough for an English-speaking life (for example, Helsinki, Paris, Berlin, Madrid)
I started this blog one years ago while I was an engineer working for Finnish Nokia and learning my way into Agile and software quality. At first it was a place for my to learn better by sharing the experience.
Over the years the blog was changing. After the initial "solo blogger" period I changed the concept into a group blog and was trying to differentiate from the other blogs on Agile by gathering a real diverse set of authors. We were lucky to have a maker of an agile tool , some coaches , some developers, a manager and so forth. Many of them continue having a successful Agile-related public life with the most prominent case probably being Jurgen Appelo a trainer, popular blogger and author of the best selling Management 3.0 whose essays I was fortunate to publish a few years ago. At the high point we were getting something like 50K page views a month. While brining lots of fun running and editing such a website was, however, taking lots of time from my life.
At some point I've got more involved into product management and later as you may have noticed into Qt-based cross-platform development. Agile became just one of the important tools I was using in the work life, even my public talks are nowadays more on, for example, test-driving QML rather than on soft topics such as facilitating the problem solving. Without the continuous editorial effort the external contributors started leaving the blog yet daily readership and surprisingly stay high. So when I found myself looking for a job now, I figured I could try using this blog as an ad platform. Especially since the exact work location doesn't matter much to me.
Lately I was deeply involved in a Helsinki based startup caring after making the video calls so simple and easy to use that even grandma would use it for calling the grandchildren. Unfortunately as it happens with startups, sometimes you find yourself looking for a new position earlier than expected. I am in such a situation right now.
There are three things I know how to do well:
- Product management for the technical products. Less about the marketing side, more about the listening to market side, playing a Product Owner and shipping things (global rollouts included).
- Agile Project management - pretty much a simplified version of the above
- Mobile, mobile-web and cross-platform software development, especially all things Qt
Ideally I am looking for not a huge project where you just have to combine the things above, but specializing in any of them is fine as well.
Location doesn't really matter as long as the city is large enough for the English-speaking life. Say, Helsinki, Berlin or London would fit perfectly.
My biggest achievements stay with the companies, but there are a few private things worth highlighting. I created a number of private apps for mobiles during the last year. One of them got over 40K downloads by now (and that's pure Nokia N9 app while there are not many of N9's sold in the world), another one stays on the business apps top seller page for several months already and is the first known to me case of a real application running Symbian, MeeGo and Android from the same source code.
So if you happen to know a company in a large European city (Helsinki, Berlin, Paris, whatever) that needs an experienced engineer who also knows how to manage projects and ship products, please, refer them to this page and/or forward my CV (pdf). The closer to mobile, mobile-web or cross-platformness, the better
|Artem Marchenko CV.pdf||561.58 KB|
posted: 16 May 2012
Here are the slides and the example code.
This presentation has only minor changes from a year old Tampere version.
posted: 18 Jan 2012
Direct Nokia Store link - http://store.ovi.com/content/214273
I've released the free Daily Wallpaper for Nokia N9 a couple of months ago. Since that time it enjoyed nearly nine thousands of downloads (quite a number for this platform) and was keeping me personally entertained. Once an hour (or once a day or once a month) it is downloading the fresh cool wallpaper from flickr and every time I unlock the phone I can enjoy a new interesting photo.
Since the moment of release, the most popular request (sometimes even causing the low rating in the Nokia Store) was not to rotate the too wide images, but to cut the central part out of it. I do love the rotation, but my opinion is totally irrelevant compared to the customers. So since yesterday, version 1.1 knows how to do both rotation and cutting. Cutting is the default mode. Enjoy and, please, submit more requests or vote on the existing ones.
posted: 28 Dec 2011
For those too busy to read the whole post: from now and until the end of winter you can get Easy Discount Calculator for Symbian and Nokia N9 for 50% cheaper (1 euro in most of the countries) from Nokia Store at http://store.ovi.com/content/186742
I am a big fan of small utilities tuned for the very concrete purpose. And I don't enjoy messing with the lots of discount calculations. You know, when one headset for my phone was 49 euro and now it it is 33% cheaper, but then there is the other one that used to be 69 euro and now it is 40% cheaper. How much do they actually cost?
Simple, elegant, slick, fast!
That was exactly the reason a group of friends (Artem Marchenko, Jarmo Parkkinen, Tuukka Lindoos and Ekaterina Kuts) decided to solve and created Easy Discount Calculator, the first ever real app that runs on Symbian devices, MeeGo Harmattan devices (Nokia N9) and Android devices from the same source code. OK, Android support was a bit of an experiment, so on some phones it works flawlessly, on others it doesn't, so we offer it for free.
Top ranked and top rated after a couple of months in sales
From the sales start in September, this Discount Calculator was steadily climbing up the best seller list and is right now is the top rated and second top seller business app for Nokia N9 and just below the top page of Symbian business apps top seller list. So we figured if people like the clean UX and find the app useful, why don't we give it out cheaper for after-Christmas sales and maybe we manage to climb to the very top seller position for the business apps.
Winter discounts! Get it for just one euro or even cheaper
So from now and until the end of February 2012, Easy Discount Calculator is available for the cheapest possible price for Symbian phones and Nokia N9! That is 50% reduction of what it used to cost. Exact price is determined by Nokia store, I believe for most of the European and American countries it should be around 1 euro or 1 dollar.
If you happen to have a minute for comments, we would also love to reply to your comments and proposals at our support web-site http://discussions.zoho.com/easydiscountcalculator
posted: 18 Dec 2011
N9 is a wonderful Nokia device totally unlike the smarphones it was doing earlier. To the date it gathered a number of extremely positive reviews and is arguably the first phone able to compete the iPhone in the user experience area and in how beautiful it looks. It got a beautiful AMOLED screen that just begs to be used for pictures, new and interesting pictures. Yet finding great wallpapers and setting them manually is tedious. Well, no more. Meet Daily Wallpaper, one of the top downloads for N9 in the photos & videos category enoying several thousands downloads a month (quite a number for a device released just a month or two ago in a small number of markets).
Daily Wallpaper is a small app that every hour, every day, week or month gets to flickr, downloads a fresh photo from a group focused on gathering great wallpapers and sets it as a device wallpaper that you can see on the device lock screen. Certainly you can set choose the wallpaper yourself at any moment as well.
The app is evolving actively, new features and improvements get released sometimes once a week and while I am still working on the fresh features, I am keeping the app available for free until at least Christmas 2011, possibly longer. Later the app will become a paid one, but once you downloaded a free version, you should be able to get updates for free forever (that is if I've git the Nokia store rules correctly).
posted: 09 Oct 2011
Yesterday I was talking at the 2nd Tampere barcamp about how you can make your application automatically scale to different devices, yet allow for pixel perfect fine-tuning when needed. We used this approach for Easy Discount Calculator that is to my understanding the first real app available simultaneously for Symbian, MeeGo/Harmattan and Android (on some Android devices it runs smoothly, on som it has problems due to bugs in not yet mature the porting technology).
Unfortunately the presentation may not make much sense to you if you haven’t been to the barcamp as well, but you may like to have a look at the application on your device. Here are the links to the app stores:
- Easy Discount Calculator for Nokia devices. BTW right now it is the second in the top seller Business apps for Nokia N9.
- Easy Discount Calculator for Android devices
posted: 19 Sep 2011
A couple of days earlier, on Saturday, Sep 17 in a city of Tampere I was co-organizing the conference called Tampere Goes Agile. Conference was a big success, preparations were challenging and interesting and I should really write about it. For now, here is the slideshow for the conference photos. If you want your photos to appear here, tag them on flickr with tamperegoesagile.
There are no comments allowed on this blog (until I find time to solve the overspamming problem), but feel free to copy-paste the slideshow code to wherever you like. The best way for providing feedback is a tweet tagged with #tamperegoesagile or a blog post with a tweet linking to it.
posted: 16 Jun 2011
Even from the first time it was a huge event never seen before in the region. The reasons were three:
- The region was ripe for a big event. Agile was still in its infancy and a number of local conferences just had to turn into something big
- Excellent speaker line up. The team did excellent job attracting the best speakers one could hope for, including David Hussman, J.B. Raisenberg, Jurgen Appelo and others. Yours truly was also speaking on Estimating and Planning, though in a somewhat different league
- A unique location that is visa-free to nearly whole world. It is pretty much the only country in the world where EU, US, Russian, Ukrainian and Belorussian people can meet without any visa hassles
This year AGILEEE is going to happen again and I am glad to help with finding sponsors for it. Besides being a great place for participants, AGILEEE is also an excellent marketing opportunity with the crowd full of influence on the company purchasing decision. Last year we had people from 22 countries (twenty two!), nearly half of 450 participants were project managers and executives.
So if you happen to know a company with software industry related interests in the region or just a maker of a tool for the software developers, tell them about this post or about my direct contacts: email@example.com. skype:artem.marchenko, phone: +358-50-486-1137, twitter:AgileArtem
posted: 15 Mar 2011
Here are the slides and the example code.
posted: 11 Jan 2010
If you're not already a member of the Scrum development group on Yahoo, you really should join. There's a fortune of information changing hands and you can learn so much from the interactions. Just recently there was a huge debate on the topic of technical stories.
The underlying question the team debated was should technical stories appear on the backlog.
If they are on the backlog, it means the technical stories are to be prioritized by the PO. This may not be such a good idea considering that PO's are generally going to be biased towards prioritizing features and functionality over technical stories. Examples given were "Installing Cruise Control", upgrading DB from MySQL to Oracle, Setting up VMWare etc. Most thought leaders on the forum argued that technical stories should not appear on the backlog, overwhelmingly so in fact. But some rightfully point out that all work requiring development resources should appear on the backlog.
What does Scrum say?
If you take a look at the definition from the Scrum Guide on Scrum.org, it states:
"The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases."
"The Sprint Backlog consists of the tasks the Team performs to turn Product Backlog items into a “done” increment. Many are developed during the Sprint Planning Meeting. It is all of the work that the Team identifies as necessary to meet the Sprint goal."
So what's the right answer?
Well, my answer is it depends and it depends on the context. For example, if your definition of done includes unit tests, automated tests etc then these work items don't need to be specific items on a backlog. This is stuff that gets done by the development team and there is no negotiation. Estimates need to include the time required to complete all of these elements of the definition of done.
But what about the type of story asked by one of the members "As a development team member, I want the existing unit tests to run under CruiseControl, so that I know if anything breaks". Where does this belong?
Well this is a perfectly written story but the story really has no ultimate value for the end user at least not directly. In this particular case I'd therefore suggest the following:
This type of story definitely doesn't belong on the product backlog but would be a perfect task that could exist on the Sprint backlog assuming you're tracking tasks. I am still in the Scrum camp on task breakdown as opposed to the XP folks who prefer to work just at the story level. If you're doing task level breakdown during the sprint planning meeting then this type of Story or work could exist on the Sprint Backlog as a task and the time associated with doing this can be tracked on the burndown. Most XP folks will say this is just micro-managing all over again.
To quote Ron Jefferies: "Technical stories have been found to be an inferior idea by many practitioners who have tried both ways. I don't know of a single one who would go back." Now Ron is a really smart guy and has ton's of experience and it's hard to argue against his opinions or any of the other smart folks on that forum.
I suggest you decide how to handle this as a team and do what you (the team) think is best. I will state however that the XP folks appear to be the most progressive in forging new ground in agile efficiencies and techniques so watch what they say carefully and even consider what they say.
posted: 20 Nov 2009
I may have blogged about this previously. I have written so many blogs, I can't recall any more. However questions regarding Sprint length surface on the forums regularly.
As per usual, the answers one must give always depends on the context and every context is different than the next. So let me start with the context - this is an excerpt of a post on the scrum development group on Yahoo. Incidentally, Yahoo groups is a good place to hang out. You learn a lot from all the questions and the different contexts facing teams around the world.
A team of 5 members currently working with 10-day sprints. They haven't managed in the previous 5 sprints to have 100% of the User Stories completed. It is typically around 60-70% completeness.
There is proposal to increase the sprint duration to 15 days "because doing review meetings and planning every 10 days is a lot of overhead" according to the team.
Let me start out by stating some facts ...
The official Scrum sprint length is 30 days. However I don't think (I don't have facts to back me up on this but it's the sense I get from all the communications on all the forums) there are many teams working to 30 days any more.
Much of the Agile community agrees that shorter Sprints are better. So 2 week Sprints and even 1 week Sprints are becoming more the norm.
Why are shorter Sprints better?
1. Well we have learned from the Lean folks that shorter Sprints means less work-in-progress which means shorter cycle times and overall less waste.
2. Additionally, shorter Sprints tends to stress your process, revealing any flaws. Like no automated build process, automated test harnesses our unit test frameworks. Fixing these flaws has a tendency to provide leaps in productivity gains for your organization.
So assuming you buy the argument that shorter Sprints are better. My initial quick answer to the question is don't try to lengthen the Sprint. Rather try to figure out why you're only hitting 60% - 70% of your originally committed goals.
By the way, 60% - 70% may not be that bad, after all you have a team that is currently demonstrating a consistent output Sprint after Sprint.
So that leads me to think that either the story point estimation is not consistent, or the team is just over-committing. So I would suggest that they do the following.
Try to really assess what is going on in the retrospective. Let team members speak freely about their thoughts on the matter.
I would definitely spend a little bit of time re-assessing the size of a few completed items i.e. if the story was 10 points originally, what would they estimate the size now, after the fact. Re-assessing the relative size may well fix the problem.
Some folks, most notably Ron Jefferies, would argue why do you need to get your estimation down pat. Well in my opinion for one, predictability goes a long way to help remove team stress. So its great for a team to say we can commit to say 100 points and deliver between 90 and 110 each Sprint. The business will love you for this.
Whats good about this problem in and of itself is that Scrum is doing what it's supposed to do; surface issues for the team to resolve. And if the team feels that going to 15 day Sprints is the right thing to do, so be it - it might well be. But I would try to first figure out why 2 weeks is not cutting it. Many teams make it work so it should be doable.
Hope this helps if you're in the same boat. If not at least if it provides food for thought!
posted: 16 Nov 2009
1. How has the Agile practice evolved over the last two years?
I don’t personally think that agile practices have particularly changed in the last two years, however there is clearly a stronger emphasis on some elements more than others now.
Scrum certainly seems to have crossed into the mainstream since I started my blog. Even though it was less than 3 years ago, Scrum still felt quite new and innovative in the UK at that time. I work in the web development sector and now every company I meet seems to be doing Scrum.
Another change is the interest in agile from the project management community. This seems significant as people start to think more about how best to apply agile on larger projects. Looking at Google Trends, which shows search volumes over time, the graph below shows that search demand for ‘agile project management’ started relatively late in terms of agile adoption, and interest is still growing strongly now.
2. What would you tell someone who thinks Agile is just another fad?
I don’t think agile can be called a fad now! Admittedly it may not be for everyone, but it’s certainly not a small minority any more. Again using Google Trends to gauge search demand and therefore people’s interest in a topic, 'agile software development' has been in high demand on Google as far back as 2005 (although it’s obviously been around a lot longer than that), and has remained high ever since. I don’t think something can be called a fad when the buzz has been going for over 5 years already and is continuing to grow strongly. For anyone that hates the idea of agile and is secretly hoping it might just go away, you’d better get used to it because I think it’s here to stay!
3. What are some tools that you use?
I know this might sound like it isn’t much help to others, but we don’t actually use any project management tools or any specific agile tools. Those who read my blog will know I’m a big fan of Excel and the whiteboard, although clearly agile project management tools would be a useful addition in some circumstances, particularly where teams or stakeholders are distributed across multiple locations or projects are particularly large.
In my experience, I’ve had several development teams practicing agile web development using Scrum, and they have been able to operate Scrum on a team-by-team basis without the need for any specialist tools to help manage. Instead we have placed a much stronger emphasis on face-to-face communication and collaboration, using Excel to manage product backlogs, user stories to convey requirements, and whiteboards to provide visibility.
4. Do you think that Agile and the PMBOK can coexist?
I definitely think agile and PMBOK can coexist, although some elements of PMBOK would be irrelevant to apply on an agile project. However there are plenty of elements of PMBOK that are not addressed at all within agile methodologies, for instance project initiation, cost management, risk management and various other aspects too.
I think the problem here is that a project manager must know PMBOK-style project management methods like PRINCE2 and agile methods such as Scrum very well to be able to choose the right techniques for the right situation. This obviously demands a lot of skill and experience from the project manager and is potentially very difficult for anyone new to either method. This is where experienced project managers that have successfully transitioned to agile have a really strong advantage over others who have only really managed projects with one approach or the other. It gives them the ability to blend the methods based on the unique characteristics of their particular situation, which along with leadership skills might be the thing that differentiates a good project manager from a great one.
I have blogged about this topic before here: Agile Project Management Is Not Enough!
5. Can you recommend a book, blog, podcast, Web site, or other information source to our readers that you find interesting or intriguing right now?
Apart from my own, I would recommend various other blogs, some of which you’ll find in the sidebar of my blog. My personal favourites at the moment are Leading Agile by Mike Cottmeyer, Succeeding with Agile by Mike Cohn, and Agile Techniques on InfoQ. In terms of books, you’ll also find some books I can recommend on my blog; they’re on an Amazon affiliate widget in the middle of each page. 'Agile Project Management with Scrum' by Ken Schwaber and 'Agile Estimating and Planning' by Mike Cohn are particularly recommended.
Photo by Marco Bellucci
posted: 06 Nov 2009
Based on a recent post on yahoo forums, seems like there may still be confusion out there as to what the differences are between these two roles. Questions like, is there overlap? can the Product Manager take on the responsibilities of the Product Owner? what are the specific requirements for either role? pop up all the time.
There was a really good discussion on the Scrum Development Yahoo group on this topic and some really good points were made. So I'll try to distill this for you here and of course put my own twist on this.
I think that the founders of Scrum purposely chose a different title for a reason. They could have easily just kept the title the same. But I think there was good reason for this. And that is that the PO has a specific set of duties in the Scrum role.
How do their roles differ?
First and foremost is that the PO drives the priorities for the development team. This is done via the Product Backlog as a vehicle for communicating priorities. Essentially, a company has a certain available capacity to turn requirements into working functioning code. How that capacity is used up is completely in the hands of the PO.
In order for the PO to do this, the PO needs to understand the bigger picture. Whether or not the PO distills this information from other roles or whether he has to get this information himself depends on the company.
Based on his/her understanding of the bigger picture, there are some additional specific duties that the PO must perform (not necessarily defined anywhere):
1. Articulate the product vision to the team
2. Define the goals at the beginning of every sprint
3. Tell the story behind each user story so that the development team understands what is required. So the PO must understand the end user requirements.
4. Define or help define the user story acceptance criteria so the team knows when they are DONE
5. Be able to prioritize the stories and be able to negotiate/collaborate on priorities with the team. Negotiate priorities occurs when after taking the top priorities off the backlog; there may be some remaining capacity that the next highest priority story won't fit in to. So in those cases, a lower priority feature could be picked.
6. Must be available at all inspect and adapt points to answer questions and help guide the team empirically
Product Managers on the other hand must be able to do a whole bunch of other things, including but not limited to:
1. Defining the marketing strategies and outbound marketing communications
2. Pricing strategies
3. Understanding the positioning of the product in the market place
4. Competitive analysis
A couple quotes from the forum worth repeating here
"Scrum does not prescribe further responsibility beyond optimizing development to ensure business success" (Anonymous)
"The Product Owner role, on the other hand, is really about representing the business side and working with engineering to optimize the software (or technology) delivery part of the entire product solution." (Greg)
The best ..
"The product owner role is a genuinely new role and disruptive for most organisations, as it does not easily map onto existing roles and structures" (Roman)
In summary, depending on your situation, the PM and PO roles will be performed by the same person, a group of people or separate people - frankly I don't care. As long as there is a person dedicated to doing the PO duties and responsibilities as defined in the 6 bullets above, then all is good from a scrum perspective.
posted: 24 Oct 2009
I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.
Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it's worth blogging about this particular situation once more.
The response I received was "You're not serious you're going to ignore the PO" and "You can't be a slave to the process"
In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:
How long are the sprints?
How far into the current sprint are you?
Are there stories that have yet to start that is of similar size that you can switch it out with?
Is this a critical issue that needs to be fixed ASAP as customers are complaining and may negatively impact revenues?
Those are some of the questions that need to be asked when making that decision.
In response to being a slave to the process...
Well you're either a slave to the process or the team is a slave to any chicken in the company who shouts the loudest. Lets go back to basics and why the Sprint is there in the first place. It's designed to provide stability for the team to get stuff done. Hopefully you're doing short sprints so it's not a lot of time before the team pops it's head up again and asks for more direction.
If the team listens to whatever the next flavor of the month is, then we're back to square one where there's just chaos and nothing gets done. Seriously, smart people figured out why we need to do it this way. There is strong evidence to support that this makes a difference, a really positive difference. So lets not willy nilly and go changing plans whenever someone in the organization feels like there's something more important to do.
Moreover, in this situation, I think it's important the team asks some serious questions as to why suddenly there's a story that's so super urgent that it calls for a change in plan. Lets say you're doing 2 weeks sprints and lets say you're midway. This means in reality that 5 days ago, nothing was more important (top priority items get selected to go into the sprint). Why all of sudden is their a need to change direction so soon after. Additionally can't it wait another 5 days?
Now I am sure there are times where such a situation arises and that's fine. I would never be so hard-line to suggest that the team doesn't collaborate over this and decide what are the best options. And in such a case, it's important that the team does this.
But lets be very careful how we deal with this. Because once you do this once, it's a slippery slope after that.
So what would I do. As already mentioned above, I would sit down with the team. Have the PO explain the dilemma. Thereafter, it's up to the team to decide if there is an easy swap out that doesn't impact the Sprint goals and productivity. Ultimately if it is possible, I am sure most teams would do it any ways. Level heads should prevail.
posted: 09 Oct 2009
Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.
So how do we make sense of this all?
My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.
In order to illustrate ....
Scrum is a methodology and process that provides the mechanisms for teams to learn and adapt. Scrum however doesn't say much about the meaning of DONE and how to accomplish that. That's where XP comes in. XP has great practices around engineering discipline. It teaches us all about craftsmanship and producing quality work. I personally cannot see anyone practicing Scrum without at least some elements of the XP toolset. Be it pair programming, TDD, ruthless refactoring, emergent architectures etc.
Lean on the other hand is way more philosophical, but they have great teachings. For example, recognizing that work-in-progress is a liability is huge. If you start to think like this, you're going to minimize work-in-progress and as a result you will improve overall cycle time. With Lean, people come first. What effect does this have on your organization? Well happy teams make happy customers, better quality software, improved work culture.
And Kanban? Well Kanban helps teams with flow (i.e. cycle time, throughput etc) and almost eliminates the need for traditional sprints which I won't get into here (subject for another discussion). So many teams are using kanban boards for controlling the workflow of tasks or stories, or both.
Scrum has also been said to have problems with scalability and cross site development shops. Well Stride in it's infancy (not even sure you can call it an accepted methodology yet) has adapted Scrum to provide capabilities for better handling these sort of situations.
So what do you do?
Well in my opinion Scrum provides the best overall process or mechanism to manage agile project. It's a good base to start with and I would definitely start with Scrum. But you can't go it alone with Scrum. You have to pick and pack from other methodologies till you get what works for you.
I think Agile is evolving and most likely wont stop. And why should it. I want us to get better at it. And there's so many smart people thinking about how to make software development better. I can't wait to see what it will be like in 5 years from now.
posted: 07 Oct 2009
Poka yoke is a Japanese term that means something like fail-safing or as I like to call it fool-proofing. The idea is that instead of just telling people how to do things you design your process, your tools or your product in such a way that it becomes harder to make mistakes and easier to do things the right way.
USB cables are a good example from manufacturing. It's impossible to accidentally connect two USB printers together because of the way the plugs are designed. You can only connect a USB device to a USB host. Another well know example are microwave ovens that turn off the moment you open the door.
Poka yoke in software engineering takes a bit more creativity. Software is incredibly flexible so it's often harder to define right and wrong ways to fit parts together. First lets look at a couple of ways we already do poka yoke without knowing it to get some inspiration. Later we can look at how we can fit more of it in our process.
We have a lot of practices that make it more difficult to check in faulty code. Unit testing and regression testing together with a continuous integration system makes defects very visible very fast. A similar but older technique is coding by contract. Defining pre-, and post-conditions for every function in your code making it fail fast whenever it is called in the wrong context or with the wrong parameters.
Another concept in API design that is gaining popularity is 'convention over configuration'. Instead of letting consumers of your API configure every aspect before they can start to use it you give them a set of sensible defaults that 'just work'
Of course it's easy to go overboard with fool-proofing your process. We know that for every fool-proof system the universe just invents a bigger fool. The trick is to just fool proof the parts of your process that repeatedly cause defects. The best way to do this is to bring it up as part of your retrospective. Try to find the weak spots in your system and make them more robust by setting sensible defaults or adding tests. Sometimes even improving names in your code can improve things.
posted: 26 Sep 2009
When one looks at all the wastes, defects has to be the most obvious one. The cost and repercussions of finding defects varies depending on where in the cycle they're found. Defects found early on in the development life-cycle are way less costly to resolve than defects found later on in the cycle; the most expensive being when applications are already in-production.
Additionally, depending on when the defects are found, defects can and do trigger other wastes like task switching, relearning etc.
Defects can be very costly for an organization. So the trick with defects is that you need to 1) Prevent them from happening in the first place and 2) Find and fix them as early in the development life-cycle as possible.
So what can you do to prevent them from happening in the first place?
An interesting quote from Mary and Tom Poppendieck's book called Implementing Lean Software Development,
"If software routinely enters final verification with defects, then it is being produced by a defective process"
.... which needs to be fixed. So...
Step 1. Prevent the bugs from happening in the first place by "mistake proofing" your code
Step 2. Do whatever you can to find the bugs early on in the process while the code is fresh in the developers minds - i.e. ensure you have good functional test plans and test tools.
Step 3. Ensure a proper staging (or test environment) that mimics production environment as closely as possible
Step 4. Get the software into the hands of customers as quickly as possible, so good Agile practices help here.
Step 5. If you find defects, ensure they never happen again by keeping your unit tests current.
posted: 24 Sep 2009
Few days ago I was honored to speak about Agile Planning on Agile Eastern Europe conference that happened in Kiev on 18th and 19th of September. I promised many people to share the conference photos, so here is a slideshow. I also added some pictures of the Kiev and its people to help you feel the atmosphere and
showcase my great photo talent If you prefer looking at photos one by one, you can find them in this flickr collection.
I hope you'll like the pictures.
posted: 22 Sep 2009
People work harder when there is someone looking over their shoulder.
I'm going to be completely honest with you here. When I work alone I spend a considerable amount of time surfing the web, reading email, twittering (you can follow me at @mendelt) getting coffee and talking to coworkers. This means I'm spending less time working but it also means I'm constantly interrupting myself during the time I am doing work making me even less productive.
Now we don't tell our managers this because it wouldn't do anyone much good, the problem is a bit more complex than just people slacking off. What I've observed is most people have a hard time pacing themselves. We do really focused work for five minutes and then take a break. Unfortunately breaks have a habit of taking more time than they should and productivity goes out the window.
To solve this problem we need a way to maintain a sustainable pace. Pair programming is a way to do just this. Forcing yourself to explain what you do to your pair is a great way to maintain a sustainable pace and work a bit harder.
posted: 16 Sep 2009
I think I've been pretty successful in my career. But if I was better at planning, I wouldn't have achieved half the things I've achieved in my career! In fact, I wouldn't even have started some of them...
In reality, there are some things you can plan, and some things you can't. The trouble is, in most organisations we've come to expect a plan. And to meet it whatever happens. And that's just not realistic. <!--break-->
Doing detailed planning pre-supposes you know where you want to go and aren't going to be influenced too much by what happens in the meantime - or at least not without a substantial amount of re-planning. This, at least in my experience, has a tendency to give project managers tunnel vision at times.
Now don't get me wrong - I'm not suggesting for one moment you embark on a project that doesn't have a clear and robust vision. And I'm not suggesting for a moment you embark on a project where you have no idea how to achieve it and whether it's a reasonable (although hopefully challenging) goal with the available resources. And forming that into an outline plan to provide some markers to aim for is certainly a good idea, but ideally it's a high level roadmap rather than a detailed plan.
Coming from a traditional software development environment, I realise this sounds slightly mad. And I must admit it takes a certain amount of maturity and experience to recognise that you can't really plan in detail up-front if you want to retain any flexibility, as the real requirements, risks, issues, priorities and opportunities all tend to emerge when you start to build and see the software in action.
Most organisations are not be ready to accept such a radical idea - the idea of acknowledging you don't really know what you want - certainly not for sure - and you don't really know what you're going to get for your money, or when. So, as a minimum, a clear vision and outline plan are essential, but be careful to keep them to a high level.
Rather than a detailed plan, I prefer to see a strong vision, a strategy, goals, and a roadmap (high level outline plan). The tactics to achieve this, for example the precise features and all the tasks to deliver them, can vary along the way and are best not articulated up-front. This enables the team to discover the details when they are in a better position to do so, and allows them to change direction rapidly in response to changing circumstances.
This, when you think of it, is the very meaning of agile...
Photo by tanakawho
posted: 16 Sep 2009
Interestingly, this weeks blog covers the 6th waste - Delays - as identified in Lean. How appropriate after the long delay since my last blog post on Task Switching. Herein lies an example of what Delays in software development can cause. Delays introduce discontinuity and trigger additional wastes already covered like Relearning. It's important in any process, including software, to have continuity. This reduces cycle time and minimizes other wastes like Relearning, Task Switching etc.
Focus on the end-to-end process, not individuals
It's important to identify Delays early on and try to rectify them as soon as possible in order to maximize team productivity. It's interesting... I have been reading many interesting threads on the Agile forums lately about measuring developer productivity, team productivity etc. Managers/executives have us focus our efforts and attention on individuals instead of looking at the end-to-end process to find the real issues that address productivity and enhance team effectiveness.
It's actually unbelievable to me that organizations get trapped like this. Always thinking that Developers are the bottleneck. If we learn from what Lean teaches us, simple value stream mapping can uncover the real gems that can increase productivity.
Reducing delays between sprints
It's important to ensure that the value stream is tuned for maximum efficiency where there are little to no delays at any point in the process. For example, yesterday someone posted a question on one of the forums asking if it's possible to not have delays between sprints. Well of course it is possible but it takes hard work to get this right. You have to ensure that the backlog is properly groomed. So you need an effective PO who understands the market, the client etc. You need well written stories. You need estimates from developers early so the PO can make decisions ahead of the planning meeting. It's all about designing delays out of the system so that there are smooth hand-offs at all the transition points. And it's worth mapping this end-to-end process and identifying delays at each of these points.
So what are some of the more common delays you can look for and what can you do to avoid them?
1. Project approvals - waiting for projects to get approved is the most cardinal of all sins as this usually has handfuls of developers sitting around twiddling their thumbs and is a blatant disrespect for peoples time. Coupled with this is the fact that waiting causes dissatisfied and disgruntled employees and only serves to ruin the culture in an organization
2. Waiting for a proper prioritized list of requirements - so that work can get started.
3. Waiting for resources to become available - generally impacts projects significantly. This one is not necessarily an easy one to solve as there are generally budgetary concerns. But this then begs the question - is the company taking on too much? You can't be successful if you're not focused and properly staffed.
4. Change approval processes - well you don't want to hear my opinion on this. Suffice to say, these processes need to be eliminated entirely. And all Agile processes inherently solve these problems. Shortening Sprints helps big time.
5. Increases in work-in-progress - The more work-in-process, the more developers have to wait before they can deploy their code to production.
6. Delays getting client to sign-off on acceptance tests - We have a services business and we find that this is a huge problem for our organization. Not getting sign-off is just a liability for the company as you're not getting paid until you get sign-off
Take the time to assess where delays are occurring and I can guarantee you that the effort spent doing this is hugely beneficial to your productivity, efficiency and overall bottom line.
posted: 16 Sep 2009
Lately I've seen a couple of doom scenario's scetched out for agile. It seems agile is dead or at least dying at the hand of the PMI. I don't want to bash the authors of these articles. I respect them and agree with most of their arguments but not with their conclusions. Agile is changing, sure, but it's not dying, we're all about embracing change right?
At it's core agile isn't a process or a methodology, it's a set of principles with a framework of practices to support them. One of the most important principles is about change, not just in our requirements but in our process, our organization and even in change itself. Agile is about improving your process, trying out new things checking them against our principles and core values and keeping what works.
Agile has never stopped evolving. We've been incorporating ideas from other fields into our set of practices like kanban and self organizing teams. And we've been trying out new ideas, we're going from TDD to BDD, we're branching out into agile software architecture with SOLID principles and emergent design. One thing that's important to notice is that many of the new ideas in agile aren't actually very new and come from other area's.
With that in mind it's not really strange to see agile practices being taken up in other environments too. Not every organization is willing or able to support the constant evolution required for real agile implementations so they do the next best thing and pick up our established ideas and practices. We've been supporting this ourselves for some time by supplying pre-packaged sets of practices in the form of Scrum, DSDM or Xp frameworks. And forces outside the agile community have been doing this too. Agile Rup has been around for some time and now the PMI is also picking up agile ideas.
It's easy to bash these agile hybrids as not being true to 'our' principles and somehow inferior and dangerous to 'our' movement. But I think the real danger comes from somewhere else.
The real danger is stagnation. If we start rejecting ideas because of where they come from we start slowing down. Don't bash the PMI because they use our practices out of context but learn from them just like they are learning from us. Take what we can use and grow. Don't let agile become the bearded conservative old fart that we set out to replace.
posted: 16 Sep 2009
Personal productivity systems like Getting Things Done or the Pomodoro technique are quite popular among agilists, and I'm not surprised. There are many parallels with agile practices, most of these techniques use practices resembling iterations, backlogs and frequent retrospectives to become more productive. I've been experimenting with a couple of these but once I started using these at work I found that these don't automatically work in a team setting.
Personal productivity isn't team productivity.
In an ideal world a team consisting of very productive individuals is automatically a productive team. Unfortunately the real world is far from ideal. Because teams are very interdependent optimizing the work of a single team-member will not automatically optimize the whole. In many cases local optimization like this might even be cause the team to become less productive. Lets look at what's causing this and how we can avoid it.
One of the ways to become more productive as an individual is to reduce interruptions. Making someone doing complex work switch between tasks a lot by interrupting them will make them far less productive, not only because the interruptions take time, the act of switching between complex tasks takes a lot of time too. A large part of personal productivity systems is avoiding interruptions. Unfortunately avoiding interruptions in teams often means avoiding communication. Communication is critical in a team.
Another way to get a big productivity boost is working with to-do lists. By listing and prioritizing tasks you can streamline your work. But in a team setting personal to-do lists can be problematic. People working from their own to-do lists instead of the team backlog can make coordinating work hard, it creates invisible work in progress and when people start planning their work too far in advance to-do lists can introduce rigidity into the team.
Aligning personal- and team-productivity
So should you only use GTD at home to organize your gardening duties? Of course not! There are a couple of things you can do to align your personal productivity with the productivity of the whole team.
The temptation to keep your head down and just steam through your own tasks is often big. For example the pomodoro technique gets is name from the kitchen timer used to time 25 minute periods where you need to do focused work without any interruptions. Pair programming can help to still get these periods of uninterrupted work without losing touch with your co-workers. You shouldn't count questions from coworkers as interruptions. They're part of your work. A way to deal with these is to add them as priority items to your lists.
Keep your todo lists short and up to date.
To-do lists are great for streamlining work. If you make your lists too long you're planning too far ahead. A list that contains more than a day of work probably contains work items that should be on the team backlog. Claiming too much work for yourself will prevent your team-members from working on high priority items.
Stay transparent, give coworkers access to your lists.
Try to keep your lists in a public place. Write them down and put them on a corner of your desk. Communicate the items on your list during the stand-up. It's important for the team to know what item is on who's list when priorities change. Work items may even become obsolete.
When done right personal productivity systems can become an asset in a team. I've been experimenting with these for some time. I noticed that reporting on work done and work planned during the stand up became easier because I was tracking my work better. Tracking time (or pomodoro) spent on a single work item also made it easier to spot potential problems earlier.
posted: 16 Sep 2009
I've been doing agile development for quite a few years now, and seen many benefits. But one of the most remarkable things of all, is how so many teams can quickly get good at predicting what they can deliver, and deliver on time, even if they were hopeless at estimating before!
<!--break--> For decades, delivering on time has been the holy grail of software development. So this, for me, is one of the most compelling reasons to do agile development. Here is the secret to consistently delivering on time:
Like most great things in life, it's actually very simple. That's really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.
You'll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.
Trust me, it works. I have seen it work in many different teams, time and time again. It's a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.
posted: 16 Sep 2009
I must apologize to you all for the lag in this series. But being August, I was away on vacation. Interestingly, getting back is hard. You have to get back into the swing of things again to get up to maximum productivity. There's quite a bit of re-acquainting and relearning so there's waste for sure. However, I do feel I have more energy now since I am back so perhaps the waste is negated over time.
Motion - Task Switching
Waste #5 in manufacturing is defined as Motion. And motion can be compared to "task switching" in Software Development - as defined by the thought leaders applying Lean thinking to software development.
Task switching can be a big time waster. Studies have shown that if you're working on anything beyond two seperate and distinct tasks, your efficiency goes down drastically the more tasks you take on. The reason is quite obvious; working on software development tasks takes a lot of thought processing and task switching requires that your mind switch contexts all the time. Each time that you switch contexts, there's relearning and re-acquainting that needs to take place.
Additionally, if you are working on multiple tasks simultaneously, it's going to take you longer to complete the first and each successive tasks. If you storm the first task and get that out, you are delivering value to the customer much sooner.
It's important to be mindful of this. I have found in many organizations, especially software companies where there is a real casual atmosphere, it's easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.
If you're a good tough ScrumMaster, you'll see to it that priorities are all driven through the backlog and the Scrum process and that your teams are left to focus on distinct activities for maximum throughput and reduced overall cycle time in development.
Next week I will cover the 5th waste in the series - Waiting.
posted: 16 Sep 2009
In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we'll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.
To look at why fixed price is popular with clients I'll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented "As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it's spending money, at worst - wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares."
I tend to agree to some extent. Clients often don't care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don't care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don't realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?
Clients often don't trust the supplier enough to move away from fixed price to other contract types. Fixed price often seems a lot safer to a client because it allows them to push risk to the supplier. In practice this just isn't the case. The fact that a client can sue a supplier for breach of contract will not change the fact that the client doesn't get any software. Allowing the client to point fingers won't solve their business problem.
What do we need to improve our chances in fixed price?
Unfortunately we can't get rid of fixed price. But there are several things we can do to make the best of this situation.
Agile fixed price
Fixed price projects will cause an agile team to make several compromises, up front estimation is not something we're used to doing, committing to those estimates even less so. Limiting scope is also not a very agile thing to do. But even within these constraints I do think agile has a lot to bring to the table in fixed price projects. Lets look at how agile practices will help us achieve the four goals I stated earlier.
The hard part of fixed price is up-front estimation. You need time and a detailed set of requirements to create really accurate estimates. We don't have either so we have to make the best estimates possible with the least amount of resources. One of the best methods to do this is agile estimation. Even with the rough requirements you have before the start of a project it should be possible to create a set of user stories and attach rough relative estimates to them using something like story points. These can be transformed into a set of estimations using past velocity of the team. Keep in mind that it's probably a good idea to pad these estimates with a risk-factor. In my experience abusing agile estimation techniques like this will not bring you the most reliable estimates, estimates are never as unreliable as at the start of a project, but considering the circumstances it's the best option. Techniques that claim to be more reliable like function points analysis simply take too much time.
Agile risk management
Finishing stories every iteration is the best way to measure progress. A story is never 80% done. It's 0% done or it's 100% done. Everything in between is uncertain and will not allow you to measure progress. Agile forces you to finish stories every iteration giving you a clear picture of progress so you'll know early on when a project is behind schedule. This kind of risk management is very important in fixed price projects where missing a deadline can mean the difference between a happy customer and a lawsuit.
Build trust by showing working software
Actually finishing stories in every iteration also gives you the ability to show working software every time. In fixed price projects this does not seem very important. Clients don't expect to see software until the very end, and on the many non-agile fixed price projects I've been on that was exactly what we were aiming for. But when you want to build a relation based on trust with a client this is not the way to go. The best way to show a client that they can trust you is to be able to show them what you're doing. Show them working software.
Break out of the contract
Showing your customer working software has an interesting side effect. They'll want to change requirements. But because of the fixed scope this won't be possible without breaking out of the contract or by doing work outside of the contract, giving the customer features for free.
There are two things that make breaking out of a fixed price contract hard. First of all the supplier will want to bill the customer for the work that has already been done. But if you have lots of work in progress defining progress is hard, fortunately in an agile project progress is much easier to measure as we've already seen. Also clients will probably not want to pay for software when many important features are missing. Prioritizing work according to client business-value will make sure the most important features will be implemented first. It will be much easier to switch from fixed price to a more flexible contract type halfway through a project.
In situations where you can't get around working with fixed price contracts people often give up on doing things agile altogether. To me this is a bit like someone who is trying to stop smoking who, in a moment of weakness, smokes a cigarette, gives up completely and starts smoking one pack a day again. The fact that fixed price makes you abandon a couple of agile practices does not mean you should give up on agile altogether. I hope to have shown some compelling arguments for doing fixed price agile in this article.
posted: 16 Sep 2009
posted: 16 Sep 2009
In his excellent article 10 Contracts for your next Agile Software Project, Peter Stevens
"Fixed price projects and agile development are considered not to mix. I know from experience that this is not strictly true. I am also convinced that other forms are better."
I completely agree with him on this but since fixed price contracts are so common in software development it seems like a good idea to look at them a bit more carefully. In this article I want to look the problems with fixed price and why traditional software engineering methodologies are unable to solve these problems. In my next article I want to continue on a more positive note and show how agile practices will help you make the most of fixed price.
What's so bad?
The most obvious downside is of course lack of flexibility. Fixing project scope in the contract often makes it non negotiable during the project often preventing change altogether. In my experience stakeholders will change their minds during any non-trivial project and fixing scope at the start of a project will limit the quality of the end-product because it will not fit the client's wishes one-hundred percent.
Not only scope is fixed at the start of a project but price is also fixed, hence the name. Making the supplier to commit to price estimates even before the project has started forcing critical decisions at the worst time possible. The later you make a decision the more information you have to base that decision on. Agile tells us to make them at "the last responsible moment". Making them sooner is risky.
Fixed price projects are often more expensive than they should be. The rigidity of these projects often causes scope to be too large. At the start stakeholders in the client-organization will specify many requirements and features they probably won't need 'just in case'. They know it will be hard to get them in later. Fixed price projects also force the supplier to make very accurate estimates at the start of a project to reduce risk, the time spent creating these estimates are later often added to the price of the project. Suppliers often also add a fee for the extra risk they have to carry, a former employer of mine added 20% to fixed price contracts and seeing how much trouble fixed price was for them this was actually low.
Instead of aligning interests of the client and the supplier fixed price projects artificially opposes them. The client will want to stretch the scope agreed in the contract as wide as possible while the supplier will want to do as little work as possible. This often prevents good communication while increasing risk. I have yet to see a fixed price project where the client delivered an on-site-customer and I don't think this is a coincidence. Fixed price pushes stakeholders into roles that are not beneficial to the success of a project.
Fixed price and BDUF
I've heard more than once that these problems make fixed price problems especially to do in an agile way. A potential employer once told me when I asked him if they used any agile practices "We do fixed price so we can't do agile". When you look at the downsides of fixed price projects this seems logical. Fixed price has problems with some of the core agile values like flexibility and communication. The focus on up-front estimation also seems to point to big design up front or BDUF.
Unfortunately more traditional approaches won't help us either. Big design up front will not help with estimations. We need accurate estimations before the project has even started. There hasn't been time to gather anything resembling a complete set of requirements. Traditional estimation techniques like function point analysis are only as good as the data you put into them and unfortunately the data isn't very good at the start of a project. Problems with flexibility and communication are only hidden, not solved.
Fixed price has some big problems. Not only for the supplier as many clients seem to believe but also for clients. These problems don't go away by giving in to the traditional big design up front methodologies although some of the problems with flexibility and communication will be less visible. In the next article I want to look at how you'd do fixed price in a more agile way. This won't solve the problems but it will give some tools to see them coming and to make it easier to switch contracts during a project.
posted: 16 Sep 2009
Waste is a killer in any organization. But if you don't know what to look for then you're probably not going to be able to find waste and minimize it or eradicate it. This series primarily deals with explicitly defining the 7 wastes in software development so that you can start thinking about how this may affect your ability to remain as productive as you can be. This can make a significant difference to your company's bottom line.
#3 - Extra processing
Extra processing in Manufacturing is the 3rd waste and this can be equated to Relearning or Rework in Software development. The time we spend relearning things we once knew or having to rework the same feature due to poor code quality can be significant in many organizations, ergo, it's important to be mindful of this. It's probably useful to list examples that would cause extra processing in software development
If your developers don't document the code properly then later on when you're either fixing the code or making changes to the code due to new feature requirements, your developers (even the original author of code) are going to need to relearn why the code was written that way in the first place. Taking the time to document your code up front while it's fresh in your mind can therefore save the company time and money.
Some project managers assign work to developers in a haphazard manner. Although you do want to ensure there's knowledge overlap on your team, if you keep switching developers on the same features, each time a new developer takes over, he is going to have to relearn what the original developer already knows.
The earlier you find bugs and fix them the less costly it is for the organization. The most expensive scenario is when you find problems once they're already deployed to production. Partly this is due to the fact that the developer now has to reacquaint himself/herself with the code again. So if the developer spends the time upfront to write extensive unit tests, if the team takes the time to define proper acceptance test criteria then the chances of having to rework the code and worse yet relearn the code diminishes significantly
The more things you throw at a developer at the same time the longer things take to get done. Task switching beyond 2 tasks is highly inefficient as the developer has to more often than not relearn or re-acquaint himself with the task context each time he switches back.
Poor communication and recording of knowledge
Today, with the proliferation of technology, there's no excuse for poor communication. Wiki's provide a great way for developers to record knowledge about their findings. And search makes it really easy to find information. I am not advocating heave documentation here. I am suggesting short summaries of information on key decisions you made during development so that if someone else has to take over or you have to come back to that code in the future, the relearning curve is not that great.
Stay tuned for next weeks blog post in this series which will cover the 4th waste - the equivalent of "Transportation" in manufacturing processes.
posted: 16 Sep 2009
Two weeks ago I wrote an article about the virtues of sharing code in teams. Just to confuse you, this week I want to tell about a situation where code ownership actually helped me introduce a couple of agile engineering practices in a team I worked with some time years ago. Here's the story. Facts, names and situations have been twisted a bit to ensure the client's privacy.
When I got started on this project the team had already been working on the code for some time. They didn't have strict rules about code ownership but most developers had started on their own piece of code at the beginning of the project and had kept on working in the code they knew as the project went on. When I joined the team everyone had a well defined layer of the application to call their own. I got to work on the UI layer.
On previous assignments I had tried introducing TDD and pair programming. But I often ran into problems. Maintaining a set of tests is hard when your co-workers change your code and don't fix tests when they break. You end up spending extra time fixing the tests other people break and it's hard to convince people to do TDD when it's costing you so much work.
But now things were different, no-one touched code. I was free to start writing unit-tests. At first this wasn't easy. UI's are never easy to test. But I started slowly refactoring all the screens I worked on to extract the presentation logic to separate presenter classes that I could test. Slowly my test coverage got better and slowly my code got cleaner making it easier for me to implement new features.
Introducing Pair programming
Code-ownership also created extra dependencies within the team. Changes in the code usually went right across the artificial boundaries. This created an ideal opportunity for me to introduce pair programming. If someone wanted me to implement something I'd invite them to sit behind the computer with me to help me figure out what I needed to build. I was actually kinda surprised how quickly people picked up this habit.
Because I actually had the chance to be successful with TDD and because pair programming gave me the opportunity to show this off to my team members they started picking this up. The guy responsible for the data-layer actually had been doing TDD on his personal projects but had had difficulty doing it over here because most of his code was tightly bound to the database. I helped him separate the logic he wanted to test from the pure data-access code and helped him get started using Rhino-Mocks, a .Net mocking framework.
Because my contract ended I didn't see that project through to the end. I heard they started sharing code more when they got more comfortable with each others code through pair programming and they were experimenting with continuous integration now.
Lets do a project 'retrospective' and see what we can learn. Should or shouldn't we get rid of code ownership? I think we should, eventually, but whenever you get rid of something you should think of the value it brings first.
In his book Working Effectively with Legacy code Michael Feathers talks about using an anti corruption layer to shield our newly written code from getting corrupted by bad design decisions made in legacy parts of our system. These layers are a temporary fix, as the old code is upgraded to new quality standards, piece by piece it slowly move and eventually become unnecessary. Sometimes we also need an anti corruption layer in our teams and ironically code ownership, a practice I criticised in my article two weeks ago, gives us the means to implement such a layer.
Another thing that surprised me here was how easy it was to get people to do agile practices when they were introduced at the right pace in the right order. 'Refactoring' a team to agile instead of trying to become agile in one big leap actually has helped me more often. When you take small steps and be careful to take the step that brings the most value every time acceptance is easier and faster and that will make sure people will keep on improving even when you're gone.
posted: 03 Feb 2009
Photo (c) Janusz Gorycki
Donald Knuth's famous book is titled "The Art of Computer Programming". Take it from one of the "gods" of our profession - software development is "The Art"! More precisely though, it is an act of creation. Nothing surprising about it if you take a closer look: suffice it to say that no two computer programs should be the same. If you find yourself coding the some thing twice, you are doing something very wrong. Also, computer programs do not really have any material form to speak of, other than a bunch of electrons stuck in a chip of silicon - they are quite literally - pure manifestation of someone's ideas.
Let me put this in an eye-catching one-lier to focus everyones attention: software is not manufactured in a scientifically controlled way - it is created
This simple (and pretty obvious) observation does not imply that programming is a more "noble" activity then, say, sweeping floors, bookkeeping or assembling cars in the factory - the value of ones work should be judged solely by the results and not by the nature of the task. It does however have quite a few interesting and very often neglected consequences - and any software project manager (agile or otherwise) would be better off rememebering them.
First of all - a team of software developers must not be managed like a personnel manning a factory line. They should not be forced, encouraged or even allowed to repeat themselves and get used to repeatable habits of mindless kinds (time tracking and reporting comes to mind) - after all, they are asked to produce something unique, and not replicate the same thing over and over again. Routine should be fought with, and any rules that are necessary (and some are) should be simple, intuitive and make obvious sense
Second - proficiency in the "craft" obviously does matter. However, it is creativity and not craftsmaship that is the most important and desireable attribute of a good developer. A developer that has just enough skills to get going without embarrasing himself, but is creative is much more valuable than an "expert" with no "soul". Let me make a comparison to guitar playing: take Steve Vai - absolute virtuoso when it comes to technical flawlessness. Awe inspiring, breathtaking, un-human. Yet - I will choose Angus Young or Keith Richards over Vai every time, even though they have no technique to speak of. Vai's music is, frankly, quite bland and forgettable, AC/DC and Rolling Stones move your soul (there, I have alienated half of my audience :)).
Third - rules are meant to be broken. All of them. And really - it is usually after you break them, when you start achieving results that are breathtaking. The best way to break rules though is to do it only after you learn them. This may mean that the manager of a development team may at times feel uneasy, as the team will try to wreak havoc in the status quo. But a good manager will acknowledge that this is the right thing to be happening to the team and allow, more - encourage and promote - improvisation, "on the edge" risk taking, sudden strikes of "divine inspiration" and all sorts of weird behavior.
Lastly - it is quite impossible to get any sort of results from a team that is not inspired and does not believe in a value of the project they are working on. Sense of value of the work is something that is of critical importance for the success of the project
The list above is by no means complete and comprehensive. It is there to just whet your appetite. I will be writing more on this subject in my subsequent installments.
posted: 28 Jan 2009
Outsourcing and Scrum
As an employee wanting to become a Scrum Consultant, I knew Scrum, but didn’t have any customers. There was no established market for Scrum coaches nor were there any big companies doing Scrum projects. I couldn’t sell Scrum in the traditional sense, so I needed to help potential customers discover Scrum and make sure that they would find me when they got serious about doing Scrum. My solution was to build a Scrum community and this is how I did it.
If you are wondering how to become an independent Scrum coach, I would suggest starting or joining a local Scrum community. You can help make the market more interested in your chosen field and therefore in you. You can find other people who share your vision. You can become a magnet for requests for information. You can create an environment where you can meet new customers. You can do all this without a marketing department.
Inspiration from Open Source
Back in 2000, I joined the board of the Swiss Open System User Group (“/ch/open”), an established but at the time “dusty” user group, whose members were drifting away from the organization. At the same time, the Linux User Group Switzerland was an energetic and dynamic club, thanks largely to their biweekly “LUGS-Meets”: an interesting talk and quality community time. At /ch/open, we adapted that concept for our members, and the
Open Business Lunch was born. And yes, it helped revitalize the organization.
The consultant-evangelist's challenge: finding customers
Scroll forward to 2007 and I am facing a similar problem. If the company is not already convinced to use Scrum, the sales cycle is too long. A man does not live on marketing alone, so I had to find companies that had already decided they wanted to do Scrum, or better yet, these companies had to find me.
What would it mean if there was an active Scrum community in my area? For one, potential customers and partners could find me (and other Scrum Gurus) easily. Other evangelists and early adopters could help carry the message to their companies. And a regular event would be a pressure-free opportunity to network with potential customers and partners.
How I started the community
I started out blogging to establish a relationship between myself and the community. My goal was to write frequently about interesting, Scrum related topics. If they can’t find you in Google, you don’t exist. If you write often, Google will make it easy for people to find you. The blog is where customers will find you when they are researching a topic. Even offline, you can refer customers to your blog (and demonstrate your expertise) when they are confronted with a problem.
A regular event is an opportunity for a conversation.
Then I started to hold a regular event, the Scrum Breakfast for potential members and customers.
“The Scrum Breakfast is monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO's, executive and operational project managers. The program starts with a short presentation about an interesting topic around Scrum. A moderated discussion among the participants follows the talk to encourage an exchange of know-how and experience.”
The time slot competition at breakfast was the lowest, so that determined the time of the event. I was able to publicize the event in existing user forums (like
deutschescrum), which would not have been true of a commercially oriented event. I gave the first talks myself, but after a few events, people started responding to the call for participation.
Reach out to other organizations
At the same time, I reached out to other organizations, like /ch/open, Jugs, Reto Hartinger’s Internet Briefing, offered to give talks (for free, or course) about Scrum. And at the end of each meeting, I invited people to join us at the next Scrum Breakfast.
I sent out a monthly newsletter to anybody who was interested in the event. This announced the coming event and was also an opportunity to highlight recent blog articles or announce upcoming courses. I did have to strike a balance between Scrum Breakfast and “private” announcements. The SPAM filter is only a button away.
Expanding the community
After a few Breakfasts, a colleague from the SwissICT, Switzerland’s largest IT association, suggested that a more formal Scrum user group would be the logical next step. Anchoring Scrum into the broader IT community would help market acceptance. He put me in touch with Reto Maduz, a Business Unit Manager at a leading Swiss engineering company which had also started publicizing Scrum and Agile Methods, and together we founded the Lean Agile Scrum Group of the SwissICT. The Scrum Breakfast became an official event of the L-A-S-Group.
My colleague was right. The impact of associating the Scrum Breakfast with a larger organization has been dramatic. The latest Breakfast filled up two weeks before the registration deadline. A core group of 10 people is now working on everything from a website to organizing events and writing articles for the press. We have received our first requests from other organizations for speakers and articles. And customers have reacted positively knowing that their suppliers are active in the group.
How long did it take?
In October, 2007, I held the first Scrum Breakfast. Shortly thereafter, it was clear that my destiny was to become an independent consultant. At that point, I started writing my own blog. In April, I was independent with my first customer (but not one I found through the community). In June, my work starting bearing fruit - Artem’s inquiry if I would write for ASD was one of the first requests coming out of my blogging. By October, I had found my first project through the community.
As I write this in January 2009, I think I have found a marketing partner for my Scrum courses. At least one person is considering a job offer he found through the community and two independent consultants are starting to reach out to potential customers through the community. So 18 months later, the community is working for me and for its members.
posted: 27 Jan 2009
Last week a second Agile Dinner was held in Tampere. It eventually made me find time to publish photos and my lighting talk presentation from the first dinner that was held in Tampere on December 4 2008 and had a great success.
To make this post at least a bit useful to the people who haven’t been present on the dinner, let me share with you how easy it is to get an Agile community started. The plan consists of five steps:
In our case the whole process tool less than a month from the original idea posted by yours truly in the beginning of November, to the finding of a courageous organizer Antti Tarvainen in mid-November to the actual dinner in the beginning of December.
If you ever took part in organizing similar lightweight gatherings, please, share your experience in the comments.
posted: 26 Jan 2009
Picture courtesy of papalars. on flickr
We did it! The project I've been talking about all this time has finally gone live and is now being used in production. Pretty much everything worked fine on launch day as well, which was nice. :) In this installment of My First Agile Project, I'll talk about the last week of the project and where we go from here.
The last weeks of any project are pretty hectic and this was no exception. Our last week was a weird one though as we were theoretically in a code freeze (more on that below), and we still had to finish final testing, and we had to be done by Thursday so our database admins could start the data conversion first thing Friday morning. We all pretty much ran around like chickens with our heads cut off all week but once Friday came a weird sense of calm had settled over most of us (it might have been a fog of fatigue or brain tiredness, it was hard to tell). The DBAs had run through the conversion process 29 previous times so while they were working, it wasn't some new process. The conversion process ran like clockwork, even finishing a few hours earlier than projected, and on Sunday we began the final Go-Live steps.
Sunday morning when I got to work, there were still some final conversion processes going on so a couple of us got to the important work of setting up a big screen TV and some seating to watch the NFL playoff games that were going on later. Most of us didn't end up watching much of the games but the Go-Live Lounge, as we called it, was a fun place to have a break. Also, Go Cardinals!
During the final week, we had determined that there were a couple of smallish fixes that we would need to put in before doing any real work on the system. Of course we all wish these things would have been found earlier but these things happen. Because we were so paranoid about the data conversion process, we had done a code freeze and decided that we would do the conversion using the same code that had been used the week before. This meant that we would do the conversion on the same code, then update the code to include the fixes, then bring the system online. The fixes were important enough and small enough that we all decided it was okay. If something broke, we had backups anyway and could roll-back. We finished the conversion process early on Sunday, did the update, and brought the system online in the afternoon for "sanity testing", just to make sure everything was working.
Once the first testing was done, the team started putting real work into the system from the past days where everything had been down. This part took a lot of coordination. Since this is a billing system, we need to make sure people's payments went in and nobody got into any trouble with money not being in their account because we had been down. We need to post payments, make sure all the money was distributed and invoices were generated so it would all look seamless. It's a credit to everybody involved that I don't think anything noticeably wrong went out to customers.
I ended up being at work 11 hours on Sunday and others were there longer than that. I shudder to think how little sleep our DBAs were running on. Luckily our management had made a big trip to a nearby warehouse grocery store to stock up on a table full of bad-for-our-health but delicious goodies to help keep our batteries charged.
We were all back at work Monday morning as well, to make sure everything looked okay and to start our list of things to fix. We put a couple of minor fixes in Monday afternoon but nothing too ugly. I think the worst thing we forgot was that I left the wrong starting check number hardcoded into my code so the first batch of checks were numbered incorrectly. Luckily, the fix for that ended up being a better solution than we had originally written so it worked out alright. Monday evening our Product Owner made the final decision to go ahead with the new system and not roll back to legacy. In celebration a coworker played the Peanut Butter Jelly Time song over our building PA system (an inside joke on the team), without knowing that our CEO and Senior VP were still in the building. They know us though so I don't think it phased them.
Tuesday was perhaps the most nerve-wracking day of all, being the first day people would be back at work and using the system for real. It doesn't matter how much you test or how comfortable you are with a system, the day people start really banging on it and seeing your stuff in action is fairly frightening. I found an issue or two with some of my stuff that hadn't been exercised enough but overall nobody found anything especially ugly.
The Go-Live Celebration Cake - The text says "Because going live sometimes requires coming up with new ideas so rad you have to create new words just to be able to think of them" Thanks to Amnon, Tom, and Grace!
Thursday was the first day where we went back to Scrum for real. We did a 15 minute stand-up meeting in the morning and had our first Sprint Planning meeting that afternoon. Boy, it felt good to be back to planning and sprinting for sure. We're going to do 1 week sprints for the next couple of weeks to take of some things we pushed back to after Go-Live. We had a fixed deployment night of Wednesday so anything we want to get in has to be done and tested by then. Because of this I don't think 1 week sprints will work for us long-term. By the time we do a planning meeting, work, and test our changes we won't be able to get a lot done in a week. Our plan is to move to 2 week sprints in a few weeks so we'll be able to compare the two approaches.
Our plans from here on out are far from decided. The team knows what we would like to do but we'll have to see how much influence we have over things in the coming weeks. What we hope to do is do our 1 week sprints on this project only for a few weeks. Then we'll move to 2 week sprints and start moving in tasks from our other long-neglected projects into the plan. The big benefit of this plan that I've tried to explain to management is that we can work on multiple things at once, or put all of our effort toward one thing. We've got maintenance tasks to do, new stuff to build, and a big upgrade coming before too long. A multi-project Scrum plan seems like it'll work very well. But we have to deal with the fact that we may very well have lost enough credibility with the exploded timeline of this project that our options are limited. I hope not though and the team and I will sure fight for our vision.
Now that this project is over, I'm going to change the focus of this column as of this installment. I think this is going to be the last My First Agile Project. Next week I'll return with a new name (suggestions welcome) and the column will be following my team as we navigate the changes to our status quo from the past year and a half. I hope to document the plan as I described above, as we move to multiple projects, but whatever happens you'll hear about it if you stay with me.
Thanks for reading My First Agile Project. If you missed any of the past posts, there's a handy table of contents to the whole series below. I'd love to hear what you think in the comments below. One of the best things about writing this series is the great comments people have made. Thanks again and Stay Tuned next week. Same Agile Time, Same Agile Channel!
My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool - VersionOne
Part 10: 5 Important Issues For Teams
Part 11: A Tale of Two Dark Clouds
Part 12: The Good, The Bad, and The Ugly - Our Retrospectives
Part 13: Reflecting on The Decline of Agile
Part 14: Did We Need A Coach? Does Anyone?
Series Review: So It's Come To This - The Year In Review
Part 15: The Last Mile
Part 16: Go-Live - The Final Frontier
posted: 21 Jan 2009
Picture courtesy of cole24@Flickr
At the end of the sprint, the Product Owner, Team and Scrum Master meet to review the progress of the sprint. The product owner has to evaluate the state of the project so s/he can decide what to do next. How does the Product Owner ensure that s/he gets a complete and correct understanding about the state of the project, including all inconvenient truths? Here is a simple agenda/meeting template to follow, to make sure all the bases are covered.
Last week, I introduced that concept of a Sprint Contract to define the parameters of the sprint. The factors Scope, Quality, Time and Cost will be familiar to any project manager. Scope is defined by the stories and in particular their size. Quality is defined primarily by the definition of done. Time is fixed by the sprint duration. An upper limit on the costs is set by the team size * sprint duration, after adjusting for absences and other tasks.
A simple sprint review needs to
The Scrum Master should take a few minutes to review and summarize the agreement between product owner and team. How many stories? How many story points? What is the definition of done? How much effort did the team plan to invest?
Next the Scrum Master should present a summary of what the team actually accomplished. How many stories achieved done? How many story points? Did the team invest more, less or the same effort as planned? If there were any important differences, now is the time to make them visible.
The Release Burn Down chart is the primary tool for measuring progress and scope of the project. Scope, progress and estimated completion date are all clearly presented in one easy to interpret chart. Everyone in the project should see the update release burn down chart after each sprint. It's even better to keep it posted on the wall.
Is this enough? Beyond the basic burn down chart, it might useful to keep an eye on the other parameters of the project, i.e. quality and cost.
Monitoring quality builds confidence in the product and keeps your technical debt under scrutiny. The number of unit tests and acceptance tests defined and passed should increase every sprint. Insufficient tests are warnings that technical debt is accumulating or that requirements could change suddenly as the project nears completion. A rising number of open bugs may be a sign that the quality is not sufficient. Your next retrospective would be a good to time ask yourselves how to produce fewer bugs.
I think the main reason for monitoring work invested in to make sure the resources are not being diverted from the project. Monitoring budget in actual money will keep your top management happy and make your Product Owner's life easier. Budget can be tracked with a burn down chart, just like scope, and the budget divided by burn-rate should be sufficient to cover the remaining sprints.
Your team is only allowed to demonstrate finished functionality, i.e. meets the definition of done. My experience has been that trying to demo unfinished functionality causes trouble -- things which haven't been fully tested often break. Everyone should get a chance to talk, so each developer should demonstrate the functionality s/he was primarily responsible for.
As a product owner, you should ask questions and explore. This is a demo of product which your users will use, not a tour through the mine field. So everything you see should work or fail gracefully.
Once you've seen everything that is done, you can discuss briefly anything which was not successfully delivered. Why wasn't it delivered? What needs to be different, so that it can be completed in a future sprint? Or do you need to rethink?
Here is a sample agenda for the meeting, with timings for a 2 week sprint.
Present: Product Owner, Implementation Team, Scrum
Duration: 1 hour per week of sprint length
Confirm that the team has delivered on its commitments
Review Sprint Contract
Confirm that the project is on track
Review & Discuss Release Burndown Chart, other key points as needed
Examine the functionality which has been delivered
A spontaneous guided tour, led by the developers, through the new functionality in the product.
Product Owner and Team
Discuss functionality which was committed but not finished
Understand what happened and why, but save deeper investigation for the retrospective
Product Owner and Team
Up to 0:10
posted: 20 Jan 2009
Lean Software Development has its roots in Toyota Production System and it helps software organizations optimize their processes and production methods in order to deliver their products to the market much faster and with better quality. Lean movement can be considered as a new development method that tries to identify and eradicate all problems and "disabilities" of old methodologies like Waterfall. Lean puts main focus on people and communication - if people who produce the software are respected and they communicate efficiently, it is more likely that they will deliver good product and the final customer will be satisfied.
Lean Software Development subsequently gave birth to Agile Software Development methods and its main branches like Scrum or Crystal Clear. For many people who know the subject Agile is just another word for Lean or Lightweight.
In one of the most popular books on Lean subject, namely "Implementing Lean Software Development - from Concept to Cash", Mary and Tom Poppendieck explain how to implement Lean by following seven principles - principles that are some kind of Lean commandments:
If this brief introduction to Lean Software Development is still not enough for you I strongly recommend buying and reading Poppendiecks' book "Implementing Lean Software Development - from Concept to Cash".
posted: 19 Jan 2009
Photo (c) Janusz Gorycki
Once upon a time, people believed that the earth is flat and the sun revolves around it. Then Copernicus came and offered the theory that matched the observed reality better. Then Newton attempted to explain why planets revolve (among other things). Then Einstein pointed out where Newton was wrong and straightened the theory to match the needs of his contemporaries – very soon to be superseded by a bunch of crazy physicists who invented quantum mechanics. These days, we pretty much know for a fact that quantum mechanics is wrong and we are in a search for a better theory. Now, all of the above theories have a couple of things in common:
What does this have to do with Scrum?
Well, everything – you saw that coming, didn't you? All the development process definitions are theoretical models of the real world, just as physical models are. And they break in very simmilar ways. And the new, alternative methodologies are ridiculed and fought with similarly. And eventually become mainstream and break too.
So, don't believe for a second that Scrum (or any agile methodology) is immune from this process. Scrum will be replaced by something better – just you watch. Right now, agile methodologies have just become mainstream, having relegated the previous models to the status of the 'flat earth' theories. Which is precisely the moment when they are doomed to start breaking in more and more situations – and the paradox is that many these scenarios were created by the very fact that we have become so much more efficient thanks to using agile development methods!
So the question is: does Scrum (or any other agile method) still work now? Well, I would say that it mostly does, but in some scenarios – it works just barely. And if you attend the ScrumMaster training, they will introduce you to all the caveats, patches and workarounds that are being currently applied to the „real thing” to make it still work in a real world. Like – what to do if your customer or a product owner is not embedded in the team – in the case of my team, they are on the other side of the planet! Or, what do you do when the customer will absolutely not accept anything else than a fixed price contract? Pass on the contract, as the Good Book seems to suggest? But see, I happen to like the money that the customer is offering, so I thing this is just crazy talk.
I can safely say that there exists one development methodology that is guaranteed to be matching your needs always: it is called „common sense”. Really, you happen to know much better what the needs of your projects are then Scrum consultants. You do need to familiarize yourself with what they are offering, you do need to read all these books. There is a lot of good practices described there, that will make your life easier. If you are crazy about certifications, by all means, go on, make yourself a ScrumMaster. But then – pick and choose. It is ultimately your responsibility to design your process so that it works for you. If the result ends up not resembling the „standard” process – that's too bad for the standard.
posted: 14 Jan 2009
Picture courtesy of Photocapy@Flickr
At the beginning of each sprint, the Scrum team and product owner negotiate the scope of the sprint. They have a limited amount of time to discuss and agree on the sprint backlog. The product owner wants functionality implemented properly and to invest development dollars wisely. The team wants a mandate it can fulfill. And everyone wants the meeting to finish on time! Here is an agenda (complete with a downloadable template) to follow so that your sprint planning will be successful.
The purpose of the Sprint Planning Meeting is for the Product Owner and the team to negotiate what should be accomplished during the sprint, or as I call it, the sprint contract. (Scrum actually defines two meetings, a negotiation meeting with the product owner and a "let's figure out how we are going to do this" meeting among the implementation team. But I'll talk about the latter meeting another day).
Even though we value customer interactions over formal contracts, contracts can still be useful and I like to talk about a "sprint contract". It is simply an agreement between the Product Owner, who agrees not to change his mandate before the end of the sprint, and the team, who commits to delivering a defined set of functionality by that time.
One of the best kept secrets of Scrum is that a project consists of a series of fixed time, fixed quality and fixed scope mini-projects, where each mini-project has a cost ceiling. Sum the results of all the mini-projects together and you have your release.
Since the sprint length, team size and definition of done are defined and fixed for the duration of the sprint, only the scope might vary, and even here, the team strives to define and fulfill a commitment.
Cost depends mostly on hours worked. The upper limit is known, but since things happen - like getting called to help another project or an unexpected doctor's visit - the limit is seldom reached. So you have a cost ceiling.
Quality is expressed though the definition of done, and should only change occasionally.
As all the parameters are fixed for the duration of the sprint, the only thing to agree on is the scope. Although not a parameter of the contract, the expected velocity helps set the expectation of how much can be accomplished in the sprint.
The Scrum Master moderates the meeting, but the Product Owner comes with the agenda. S/he wants functionality delivered and to ensure that the overall project is on track.
Regardless of the length of your sprint or size of your team, preparation is the key to finishing on time. If you are unprepared, the meeting can really drag on!
Before you start, the Implementation Team(s) should have seen, understood and estimated the stories. The stories should be small enough to implement in one sprint. The acceptance criteria should have been defined; this greatly improves your chances that the product owner can accept the implementation on the first try.
The team should know how much capacity they have available. So vacations, training, company events, and other commitments should be known and accounted for before the start of the sprint. Some events are unpredictable, in which case you just make a reasonable guess as to how much capacity they will consume, agree with the Product Owner on priorities, and then accept some stories as "conditional" - those you will do if you have time.
I have used this structure in a number of contexts, including a case in which the product owner paid for the team by the hour and another with distributed teams on two different sites. How formal you need to be will depend on many things, including the size of the project, how well the project is going, the commercial relationship between product owner and team, how well parties cooperate, etc. The more challenged the project, the more you need to dot you i's and cross your t's.
You can download the meeting agenda, which also includes suggestions for time-boxing the individual sections
As Scrum Master, I have found it useful to confirm the Sprint Contract with an email to the Product Owner. A picture of the task board, a pdf of the spreadsheet or a screen dump of the wiki page can be an effective way to capture the agreement. Everyone is clear on what should be done and both product owner and team have a solid basis to examine the success of the sprint and the overall state of the project at the sprint review.
posted: 12 Jan 2009
Picture courtesy of Dru Bloomfield on flickr
Welcome back to My First Agile Project. I spent a few weeks doing as little as possible for the holidays but now that I'm back at work we're starting to head toward the actual end of this project. For real this time; barring any natural disasters, stress-induced insanity, or alien invasions we should be live by the end of the month. So the next couple of posts in this series are going to be about the end of My First Agile Project as we complete this and transition to whatever comes next.
As I've discussed before, we've missed a couple of other deadlines in the past but this one just feels different. On past deadlines, when we thought we were close enough to done we'd find a 3-day weekend and try to decide if we could finish everything by then (converting all of our old data takes a long time so we have to basically shut the company down while we do it). Of course, things come up and we're too optimistic so when it comes down to it we've had to abandon the previous dates. We thought we were going to be able to do it at the end of November but again we missed it due to changes being made at the last minute and unforeseen problems. This time though, our list of remaining issues is small enough that when we decided on this new date we were all a lot more comfortable with it than in the past. This feels like an actual date of completion for everything, not a deadline we're rushing to meet.
That doesn't mean we're not stressed, this project has been almost 2 years in the making and coming to the end makes everyone wonder just what we've missed and how things will really go once we're live. But overall, not having the stress of being forced to work faster just to finish everything before an artificial feeling deadline is much better.
Now, one thing that's missing from this whole process is Scrum or Agile. In previous installments of this series I've mentioned how we drifted away from using the Scrum processes when we thought we were getting close to the end and since the end kept moving away, we never went back to it. We've been going in and out of scramble mode for months now, with the only plan being that we work like crazy on our various pieces of code trying to squash bugs found in testing. This is obviously sub-optimal and I wish we have kept our discipline about planning and sprinting. Although I do wish there was more to read out there about the actual nuts-and-bolts of using Agile/Scrum at the end of a project. If you have suggestions for reading material, please comment at the end of the post.
Side note on coaching
I've been thinking about coaching more since I wrote Part 14 of this series and I think this is a place where we could have really been helped by an outside coach. Having somebody who could have helped us with the nuts and bolts of how to stay on track as we near the end would have been great since we obviously were just stumbling around in the dark. I'm now of the opinion that if you're doing your first Agile project and it's more than a year, you should find a coach after a few months to see how you're doing, then check back in with that person periodically. I'm not even sure if Agile coaches would work this way but I think this would have helped us tremendously. The end of a project is a chaotic time and it's easy to get lost.
Okay, back to the topic at hand. The last week has been basically a wrap-up week for a few of our bigger pieces. I finally finished 2 reports I'd been assigned months ago and have rewritten multiple times since then as new requirements came in (if you've been following me on twitter you've seen my cursing and threats of violence about these reports). We finalized and tested our document printing process with the folks in the company who handle printing. We don't have any more issues with either of our invoice production processes. Just the fact that these pieces are Done now is a huge weight off of all of our shoulders.
As of Friday our code is frozen and our testers will be doing heavy-duty regression testing all next week. They've pretty much been doing regression testing all along so I expect this will go well. When issues pop up this week we're going to take a hard look at the importance of the issue and the fix to see if we should put it in or wait. If all goes well, we should be able to shut everything down on Friday and start the real-deal data conversion process and put this beast into production. My fingers hurt from all the knocking-on-wood and crossing they've been doing talking about going live so in the interest of superstition, that's the end of this article. :)
Stay tuned next week for either a tale of triumph or woe, depending on how the launch went.
posted: 09 Jan 2009
Picture courtesy of Phil Romans@flickr
Peter Stevens in his newest post advices how to deal with current crisis using Lean methodologies. One of his advice is to eliminate wastes, not costs. I totally agree with it, more so it is one of the most important (at least for me) principles of Lean Software Development.
Software development organizations should always strive to produce the best products and to deliver only features that are of paramount importance to their customers. They should always try to develop those 20% of functionalities that represent 80% of the value. This need is more vivid and desired during such global business conditions. This could apply to all types of enterprises - you should eliminate all unnecessary steps and waiting periods; you should strive to get the value as soon as possible and to get only pure value without any waste.
In this post I will try to explain "Eliminate Waste" principle from "Implementing Lean Software Development - from Concept to Cash" book.
Your company can be successful by producing innovative and technologically advanced products. Important thing here is that you understand what your customers value and you know what technology you're using can deliver.
You don't necessarily have to invent something that is new and unknown. Note that the richest companies just replicate good ideas adding just few features that are unique and that satisfy customers (e.g. Google Mail, JIRA issue tracker).
You can be the market and technical leader by improving existing ideas and fitting them so that the final product will attract more customers.
You have to be careful with all the processes you follow. Be sure that all of them are required and they are focused on creating value.
If you are e.g. creating lots of documents that have been always produced but nobody really knows why and you are pretty sure nobody reads them - it sounds like waste you have to eliminate. Another example of waste is when you have to wait for a long time for some other department or team to answer your questions or uncertainties and this waiting period always stops you from moving forward. Waiting is the most apparent and obvious waste - though it is not always easy to eliminate.
You should measure your process cycle efficiency and strive to keep improving it - it will probably never be perfect but it can be constantly getting better and better.
This advice is quite aggressive and when you work in old-fashioned waterfallish organization saying that you should limit the features in your system to only those that are absolutely necessary and deliver value can be perceived as some kind profanation. Well.... it's not.
The more code you have the more tests you need thus it requires more work and if you're writing tests for features that are not needed you are simply wasting time. If you don't have tests (is it possible?) it's even worse - there is bugs in a code that is not used and they will appear in the least predictable moment. I personally remove a lot of code when I take over some projects. I focus on the required features and remove all stuff that I "may need in the future". The rule is simple: if you need it, add it - if you don't need it right now, remove it. Another argument standing for writing less code is that usually with less code the overall complexity is lower and the code base is easier to understand thus maintain and support.
Last thing - the easiest way to identify unnecessary code is to use code coverage tool. More details can be found at the provided link.
I hope pieces of advice given above will make it easy to understand how to put "Eliminate Waste" principle, which is the most important one IMHO, in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.
PS. Six remaining principles described earlier can be found here:
posted: 07 Jan 2009
Around the world, companies are challenged by the financial crisis. Companies face declining revenue and fixed costs. Lean, Agile and Scrum help your company at all levels to focus on doing the right things, like creating value for your customer and eliminating wasted cost and effort, to get you company back to profitability. Lean, Agile and Scrum help you focus on getting the right Vision, Values and Execution to meet challenging times. Now is the time to start the discussion with your top management.
Your CEO wants your company to survive and even prosper during the recession (and we’d all be happier if there were no recession or if we could turn it around quickly). Together with Sales and Marketing, the CEO is trying to figure out whether and how much sales will dry up in 2009. He is under pressure to cut costs. If he does nothing, the company will be stuck with the fixed costs, but not have the revenue to pay for it.
Lean is an adaptation of the principles of lean manufacturing to software development. Pioneered by Tom & Mary Poppendieck, Lean explains (particularly to management) why agile works.
Lean thinking helps management and staff focus on the right problems at the right time:
Concentrate your efforts. Get new products and services “out the door”, one after the other. Get your corporate response times to a minimum.
Agile values ensure effective information flow. Openness, Honesty, Courage and Trust ensure that everything which must be said can get said. If your staff fears for their job, or fears the consequences of telling the truth, they will be less willing to raise difficult issues. If your staff do not trust each other to do a good job, then people will devote energy to proving themselves or shielding themselves from blame. All these activities detract from your company’s mission to create value for its customers.
Adopt agile value to create an environment where
Agile is also a set of practices. For instance, Incremental Delivery means products are ready quickly for the customer (80/20 rule) and ROI can start quicker.
User Centered Design provides the basis for creating great products and services. Get inside your users heads. Understand what they want better than they do. Create a product which meets their needs, even the ones they didn’t know they had.
Create those innovative and convincing products, which give your customers products and services that they just have to buy.
Scrum organizes work based around simple principles to produce concrete results predictably and with ever improving productivity. In a company organized around Scrum, everyone knows what they have to do:
Vision is about knowing where the company -- and each project -- is going. Focus is ensuring that people really act to accomplish the defined goals (without distraction). Flow is having a continuous supply of work, not too much and not too little, so that the company can consistently and predictably deliver new value to its customers.
Scrum rituals ensure everything which must be said does get said. Continuous Improvement means your productivity will be at least 30% better by the end of the year than it is today.
For each company, the way out of the recession means getting customers to buy your products and services. So follow Dieter Zetsche’s advice and give them something wonderful to buy.
Get you top management interested in the problem and the solution. Tell them you want to their support for a pilot project, which will 1) create an innovative new product this quarter (which your customers will just have to buy next quarter), and 2) show how Lean, Agile and Scrum lay the foundation for a highly competitive enterprise. You will need 1) their support and involvement, 2) an interdisciplinary team of 7 to 10 top people from your around company -all the experts needed to make a new product and 3) probably some coaching and training to make it all work effectively.
Then go create something wonderful!
posted: 02 Jan 2009
Last week I was giving a presentation on Agile in my Alma Mater in Ukraine. That was a very interesting event and I was positively surprised to see many 3rd year students interested much in the ways for effective software development. Here are the presentation slides published via slideshare (I changed two photos just in case they were a bit too sensitive for the corporate security):
This particular group already knew basics of Agile so we went into deeper reasons for spending time on learning Agile, its reasons and consequences. It is quite interesting to note, that all the Agile teaching (including my presentation) seemed to be based on the initiative of a single teacher and couple of times I’ve heard comments such as “that is what you [students] should have been taught on a course X". That made me wonder about the state of art in the universities.
Dear readers, if you are staying in touch with the technical universities (or are students yourself), please share your thoughts about how much agile methods are being taught nowadays in your country.
posted: 30 Dec 2008
I’ve promised myself I would actually take some vacation this week, and fortunately with small children in the house, it’s actually possible to do so! So, before the kids wake up, a blitz retrospective: High Points, Low Points and Potential for Improvement in 2009.
Becoming an independent Scrum Trainer and Coach. I really want my customers to say thank you for the work I do for them -- while I am not averse to getting paid, a satisfied customer is what makes it all worthwhile.
Scrum Breakfast Community became the Swiss ICT Lean Agile Scrum Group. I figured as a one man show, I could never mount a “real” marketing campaign, so instead, I set out to build a community. This community helps build acceptance for Scrum (and by implication, my services). But a community only functions effectively if it the community belongs to its members. And when it does, it takes on a life of its own!
Quick Polls on my blog. I started doing them because they were good for getting attention. I like to think my poll on the Nokia test helped the Scrum Community discover Scrum-Butt and think about its implications.
CSM Course with Andreas Schliep. There is a lot of debate about the value of the CSM course and certification. Together with CST Andi, I have now stood on the other side of the podium and for me the value of a good CSM Course to the participant is clear. The students learn from the teachers and from each other in ways that you just can’t get from a book. Offering Scrum training has been a clear win on the “I-define-success-through-customer-satisfaction” scale.
Writing for AgileSoftwareDevelopment.com. When I look back at my first article... well... (blush). This has been a tremendous learning opportunity. Thank you Artem for providing this forum and for your editorial encouragement!
The recession. Personally I think this economic Tsunami is going to resemble the storm Lothar, which knocked down some forests entirely, but left others nearby completely untouched (I am an optimist, and no, I have no idea which areas will emerge unscathed). Fundamentally, companies are successful by producing great products and services. Agile helps companies do that and companies will be under pressure to improve their performance. The time to start a conversation with management about Scrum and Agile has never been better.
You can lead a horse to water, but you can’t make him think. Sometimes you advise a customer, but he wants to stick with his old habits. Smile. Accept Fate. Maybe he’ll be around in year to ask for your advice again.
You can lead the horse to water and he’ll think what he wants! There are people out there who ask whether ‘Scrum has failed us’ or that Scrum is not enough and look for other solutions. Some people will find their answers in Lean, some in XP, some even in RUP. One of my first coaching customers decided he liked Scrum Ban better and tried to get me interested. I wasn’t having any of it. In retrospect, I wish I had shown more interest -- even though I am still convinced on Scrum !
Criticism of Scrum and Agile. There’s been both criticism of Scrum from within the agile community and more general criticism of agile from outside. Agile has become a buzz word which is getting applied way outside its original context. I think this is both healthy and a sign that Management is getting interested in the topic and a much larger segment of the population is being confronted with agile ideas.
Community is the key to success, both at a personal level and an ideological level. If you want to do Scrum, Lean or Agile, then build and participate in the Agile community in your area. You help make it politically acceptable to do Agile, you create a support group, and you create a network which will help you find work you like.
I would like the Scrum community to better embrace growth and change. There are people out there such as Boris Gloger (with his vision of 3 + 3 Rolls in Scrum) or Alan Shalloway (with his fusion of Lean, Scrum and Emergent Design) who are enhancing Scrum in interesting ways. The beauty of Scrum is its simplicity and universality (hint: try holding a daily scrum with your spouse or using a task board to help your kids get ready for school each day) which mustn’t be compromised. But the simplicity of Scrum means we need other building blocks to achieve the whole project effectively.
My first New Year’s resolution is to listen better to all agile philosophies to better advise my customers. There is no monopoly on the truth. Personally, I look first to Scrum and then to Lean for management issues and to XP for engineering issues. But there are new ideas out there and many are worth looking at. And even old ideas have their merits.
My second New Year’s resolution is to listen better to my customers (and readers). In that vein, I have published a doodle - what would you like to read about?
Do something! For each individual company, the key to turning the recession around is getting your customers to buy your products and services. So get together with your best people, give yourselves three months, and create a great new product that you can sell in Q2.
At this point, I would like to wish everyone a good and productive start in to 2009. May 2009 be happy, healthy and the most innovative year in your experience.
posted: 26 Dec 2008
According to Google Analytics ten most popular writings of the years are:
posted: 24 Dec 2008
Picture courtesy of Vegan Fellow on flickr
In the spirit of the season (Year-End Recap and Top 10 List season I mean), in this episode of My First Agile Project I'll be going over the previous posts in the series and giving some behind-the-scenes comments. If you've read some of the series, keep reading for more you might like. And if you haven't read any of my posts before, I've read some very kind things about the series on readers' blogs so you don't have to take my word for it when I say you will like it. If you don't like it, I'll give you your money back guaranteed. <!--break--> My First Agile Project Series
posted: 22 Dec 2008
Picture courtesy of foxypar4@flickr
Christmas and New Year is coming so it's time for some summary. I've never done this before but this year was quite awesome and I have something to be proud and loud.
Let's start from January when I moved from my hometown to the glamorous French Riviera i.e Cote d'azur (yes, the sea here is pretty much azure).
I accomplished some cool stuff at work and one that I can share with you is the new generation hotel search engine - Wallaby (which is working but still in beta phase).
In 2008 I started interesting in the theory of Agile Software Development (after few years of using it) which resulted in inviting me to contributing to the AgileSoftwareDevelopment.com blog. It was a huge challenge for me as I've never been a good or even decent writer (especially in my native language - Polish) but it appeared to be kind of success. I have on my account some pretty cool posts that appeared to be big hits like these (each of the following posts was visited more than 5k times):
And the best posts were written pretty spontaneously in less than thirty minutes without any preparation. Just some kind of a thunder in my brain that triggered my grey matter to work - that was just it.
I'd like to thank Artem for inviting me to become a regular contributor - it was a good decision for me to join ASD. I hope I will keep at least the same level of inventiveness next year :)
During 2008 I've read over 18 technical books and I shortly reviewed some of them on my private blog.
More on numbers in 2008: my FeedBurner account shows quite an increase (260% from 25 to 65 - and counting) of regular readers of my private blog - that's cool. Thank you readers!
Last but not least submitting my old and fresh posts to DZone gave my private blog a lot of visibility and doing this I increased number of visits by 1000% from ~930 to over 9K in just one month (I will not be able to keep these numbers but it anyway shows me that what I write is interesting and a lot of people like it). This is also thanks to ASD blog which gave me more visibility.
And now some conclusions. As I wrote earlier I moved to southern France in January 2008 and this was caused mostly by my previous employer - Intel - who simply laid off our team at the end of 2007. My friends who I worked with at Intel opened their own company and I was supposed to be their partner but I decided to move to France with my wife. And this was one of the best decisions we made in our life.
We live in a great place, have awesome friends and every week we do some cool stuff like skiing, hiking or just visiting some beautiful places like Monaco or Eze. And this is much more important that money that I could earn staying in Poland.
I learned a lot during year 2008, the Sun hasn't burnt out my brain (yet) and consider it pretty awesome year privately as well as professionally. And I hope next year will be even better - but even if it will be a bit worse it will still be awesome :) Yes - I'm the optimist. I'm not going to reveal my professional plans for the next year but I will probably share with you the results in 365 days.
As this is my last post this year I'd like to wish all the people around the World:
posted: 19 Dec 2008
One of the particularly interesting aspects that is missing from the simple method description is that Scrum is a powerful experimentation framework. The cadence of short iterations and mandatory reflection moments allows a team to try significant amount of improvements in a rather short period of time. You think making acceptance tests a mandatory part of all the requirements is useful? – Try it for a sprint or two and see if it works for you. Arguments about the effectiveness and social aspects of pair programming and colocation seem to be going forever? – Move the tables together and try pairing for a sprint. Some practices such as Test Driven Development might need some more time for a real try, but even in these cases them it is usually possible to figure out the required experiment length in advance. Scrum applied with a decent amount of rigor forces participants to focus on the goals and evaluation criteria of the potential improvements and arms the team with the regularly applied improvement cycle.
Most of the improvements a team tries are often quite small. The trick is that sprint after sprint these small improvements add up to a significant advantage. Famous Toyota Production System that is heavily based on the same experimentation idea allows the company to make over 700000 (seven hundreds thousands!) improvements per average year and over the decades it contributed very well to making the Toyota the biggest automaker in the world.
Agile and Scrum are no silver bullet. We still need to think and the best thing Scrum can provide us with is the thinking tools that help framing wishes with the technical and time boundaries of the real world. Scrum helps us to transform some of the wishful thinking into short knowledge generating experiments.
What about your team? How often do you try new things and how carefully do you frame these experiments?
posted: 17 Dec 2008
Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?
Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.
The first thing we did is talk about the value of each feature. What did the top priority features mean to #1 in potential hardware sales? What did they mean in potential cost savings to #2? So we calibrated the scale: 100 Value Points (VP) = X dollars of hardware sales or Y dollars of operational savings.
Next, we reviewed the existing valuations based on our new found reference values. Had the P-Ms valued the functions consistently? It turned out one feature had been substantially over-valued, the rest were pretty consistent with the actual business potential.
We used a modified Cohn Scale (more or less) to estimate the value of new features. Each estimate of value is assumed to be +/- 50% and we have Fibonacci progression on possible values. The idea that an estimate has high intrinsic uncertainty is even more compelling when discussing potential revenues or cost savings. Feature X might generate sales of 1000 additional units, but it might only be 500 and could be as much as 1500. Our actual numbers (which were based on the results of the previous point distributions) were pretty much what I suggested last week: 125, 250, 400, 700, 1250.
There was widespread agreement about the top two features. The problem is that they are both fairly big, one has an external dependency, and it is not clear whether either can implemented in the time frame of the next release. The next 5 or 6 features on the list all had similar appraisals (250 to 400 points) and were probably much smaller to implement. Which ones to do first?
To answer the questions, the P-M # 1 was asked to go back to his sales people and find out which of these features could have the most short term impact on sales. At the same time, we broke the high level stories down to estimatable user stories and will give that list to the implementation teams to estimate.
Once the product managers have this information, they can decide on how to prioritize the backlog for Sprint 1 with the goal of optimizing the return on investment.
How did the method I suggest hold up in reality? We didn’t actually play poker. With two people who communicate well, it wasn't necessary. We did discuss the value of each story as described previously. Each P-M gave his assessment; these were added together and that became the consensus value. Given that two partners are investing in a project together, in retrospect, it seems obvious that the value of a story is (value to partner #1) + (value to partner #2).
The discussion process served to build a shared understanding of how we came to the numbers. Each P-M was able to accept the importance of a feature to the other, even if a certain feature had no value to his company.
Footnote: I discoved that a variation of Business Value Poker has already been proposed: Andrea Tomasini's Business Value Game. His discussion points for determining value are more closely based on quantitative ROI spreadsheets than the questions I proposed last week. He also suggested trying to arrive at a consensus for the value of each story, as in planning poker (and as I suggested last week).
My suggestion: the goal is consensus among the stakeholders. Use whichever questions work best for you and your project. And co-development is a cooperative game. Value = Value(1) + Value(2)+...+Value(n), where n is the number of partners.
posted: 16 Dec 2008
This is my last post on AgileSoftwareDevelopment.com. I let Artem know that I need to concentrate on my own blog for a while. The success of my site is a welcome surprise for me, but it also means that it's demanding all of my attention.
On AgileSoftwareDevelopment.com I published 46 articles this year, including some timeless classics such as 10 Principles of Agile Project Time Management, The 12 Best Questions for Team Members, and Oh My God, They Fixed the Bug!. I also published my share of useless and controversial drivel, such as Professionalism = Knowledge First, Experience Last, and Specialization is Good. But I had fun writing it, and I'm glad that most of the people throwing bricks at me missed me.
Thank you all for reading, adding comments, and providing me with your feedback. Writing is no fun at all when there's nobody writing back at you! Those of you who enjoyed my writing might want to check out my own blog at Noop.nl. (Artem generously allowed me to promote it in this last post, so I'm gonna squeeze this while I can...) Besides visiting the blog, you can also follow me on Twitter, or subscribe to my feed. And even if you couldn't care less about me or my writings, then you could at least have a look at the Top 100 Blogs for Developers. There are lots of other great blogs out there. (And both ASD and Noop.nl are performing well in it!)
Of course, I also trust you will keep reading this site. I am happy and proud to have been able to support Artem and the others in making this blog a great place to read everything about agile software development. I'm sure they can keep growing the site, even if it has to be without me.
Goodbye everyone, and hope to see you some place soon!