Posts filed under ‘Agile’
Suppose you’ve got a new customer request for a feature, or maybe some great new idea by marketing people that will certainly increase sales of your product. Whether you are working in agile or a more traditional environment you are usually going to get a bunch of functional requirements (program should do a,b and c) and sometimes some non-functional requirements (performance targets, security). Sometimes you will also talk about usability – but in my experience you are never going to get “and it must look really really good” as a requirement. Most of my experience is in management systems development, so it is an assumption, but I am willing to guess that in most “business oriented” software eye candy is not a requirement.
I have recently read a great book called “Why Software Sucks?” and the basic idea of the author is that most of the people involved in making software come from very technology oriented engineering background (he uses the word geeks but lets not go there) and so to us everything is an engineering problem. We value technology and features and prefer more functionality over everything else really. So it is more natural for us to focus on features and performance and elegant solutions and mostly ignore usability and eye candy. But there is a catch – “You are not your user“. The things we value may be not the things our users value. And when developing applications we need to focus on what users want not what we think we would want if we were users. There are a lot of examples in the book of what happens when developers do what they think is usable instead of what their users would consider usable, and it’s not pretty.
But what about visuals and eye candy? Is it possible that the same thing happens here as well? Is it possible that while we as developers often consider eye candy irrelevant and even waste of resources, our users actually value it much more?
Well, some evidence is certainly out there. Take video games for example – good looking games with tons of eye candy just sell much much more. Take Hollywood – the big budget flicks with most effects often are criticized for being too shallow – and yet they are the ones that bring the most money and most people go to watch them. And how about Apple which took eye candy to a whole new levels? I have never used macs in my life, but if you ask me which is better mac or pc in terms usability – I would go with Mac.
So good looks sell but what is even more important here is that often good visuals are even more important than actual features. Macs have less software available for them then PCs. Big budget flicks have usually much less substance than independent movies. Most of recent blockbuster video games are just remakes of existing formula with almost no actual gameplay improvement.
So, yes, I believe that eye candy alone is worth a lot more than we usually think it is, even for applications that are not mass market oriented. (quick test, which bug tracking software is better: bugzilla or jira?). It’s great for first impression and thus sales and it’s great for continuing user satisfaction and thus retaining customers and creating word of the mouth hype. Features and usability alone are not enough anymore – your users demand that it also must look really really good.
I am doing some thinking about what it takes to implement Scrum in an organization that is not used to or even familiar with agile concepts, let alone Scrum. When you start a new team or a new company implementing new methodology is rather easy – you select people based on what you believe the required roles and functions are, there is no legacy to overcome and everybody is open to whatever process you are installing. There is no inertia, there is no resistance and there is no conflicting interests you need to account for.
Of course the exact opposite is true when you are attempting to implement Scrum (or whatever else) in an organization with strong waterfall culture. It’s not just about telling people about how in Scrum you do so and so, go to this meetings, here is how product backlog should look like – and then you are done. It is much more challenging because of “that’s not how we are used to do things around here” – so not only you have to be able to teach what Scrum is, but also be able to overcome years of practise of doing something else.
And that is not the hardest part. It is impossible to make all the changes overnight – this stuff takes a long time to get absorbed and interned and used to. So there is going to be some time where organization is not going to be very “organized” for the lack of better word. And yet, there are customers and sales and support and contracts that need to be taken care of, and that cannot be “pushed back” until we can figure out how to do the Scrum stuff properly.
And this brings me to the concept of refactoring. In software engineering, refactoring is the art of taking an existing piece of software that maybe is using some old technology that is a bit obsolete by now, or maybe it is written in somewhat inefficient way and taking that piece of software and rewriting it in such a way that from the outside it keeps looking exactly the same, performs exactly the same function (but better) while inside it gets completely overhauled and made more efficient, with less bugs and easier to maintain. And I call it an art because yes there are some practices and tricks which help you do that refactoring, but in the end, every software is different and what might have worked on a previous project wouldn’t work on the next one, so to be able to do this and succeed requires some flexibility and creativity.
And I think similar art form should be developed for implementing Scrum in organizations that are currently stuck in the old ways. The similar challenges apply – keep the outside interface, support clients, make the sales, while in the same time transforming the entire organization to much more efficient, flexible and adaptive proceses. And yes, even though some techniques are probable shareable, in the end every organization is different and it will take each one a unique path on its road to agile success.
The company I am working for was just acquired by one of our competitors. Not too many details are known for now, except that in a few days an integration team from the new owners will come over and start “the integration process” that will lead eventually (couple of months time frame) to the restructuring and merger.
Naturally, everyone right now is trying to find ways to “market” themselves to this integration team. For my team, one of the issues is that we are using Scrum, while according to rumors the new owners are hardcore waterfall people. Having worked with waterfall before I am sure I wouldnt want to repeat that experience. On the other hand, perhaps there is an opportunity here to interest the new guys in this wonderful world of agile.
I am wondering if anyone have experienced such a situation before, and if so, if there are some strategy that should be employed. I would appreciate any advice and/or tips on how the best to handle this. In any case, I will update this blog once we know more (and if it’s not confidential). For now, it’s time to go work on the “integration backlog”.
Happy new year everyone 🙂
Back in 1991 this message was posted to comp.os.minix USENET board:
Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-) Linus (email@example.com) PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.
For me, it showcases all agile values in just one short message. People and collaboration are more important than process, working software is more important than documentation, customer collaboration, reacting to changes rather than planning ahead.
Why this specific message? Well, some of you probably recognized or guessed it already, but for those that have not seen it before: this is the original announcement of Linux operating system back in 1991 (taken from here). Yeah, THAT Linux.
So, don’t beleive the gurus or agile trainers. Look at the source. Learn from its success. Decide for yourself.
Or why the recent “agile fails” blogs are actually a “good thing”.
According to that cycle there are 5 stages of any new technology adoption, each stage with unique adoption characteristics. I want to show in this post where agile is placed on this graph, and why it actually shows that agile is on its way to “conquer the world”.
The point where technology is invented – the “eureka” moment. No users yet, the technology is just an idea. Agile Manifesto maybe?
Peak of Inflated Expectations
Some work is done by “founders”, but the technology is not yet mature enough – more like an alpha version. There are some early adopters but no widespread use. Since the early adopters are people with some influence (bloggers, consultants, tech experts, evangelists) word starts to get out and “rest-of-us” start to take notice. This peaks at some point of maximum hype – this is a point where agile is perceived as a “silver bullet”.
Trough of Disillusionment
Once the hype peaks “normal” users start to try to use the technology… but the technology is still not ready for wide spread use. Agile specifically requires training and understanding and it takes time to actually adopt and make it useful. Because of misuse there appear failures – “we used agile for 3 months and it does not work” type of comments. In the background, the original community of founders and early adopters are trying to improve the technology but it takes some time. Arguably, this is where agile is now.
Slope of Enlightenment
As they say, it is always darkest before the dawn. Some time passes and people start to “get it”. Additionally, based on feedback from wide adoption and tons of work from the original community the technology finally reaches maturity. People realize agile is not silver bullet but it is still very valuable – “We tried agile and while at first it didnt work as expected we adapted and it is great for us now”.
Plateau of Productivity
Technology works, everyone uses it. Early adopters are already switching on the next big thing, everyone else just takes things for granted. Nobody really cares anymore. “Haha you are still using waterfall?” phase.
So what it means? It means that the recent surge of “agile fails” posts is actually a good thing because it clearly indicates we are moving forward in the adoption of agile methods and are closing to the point where it will just work. On the other hand, any technology that does not get to the “disappointment” phase will usually fail because it indicates that it did not reach the critical mass of widespread adoption to allow it to progress forward.
“Agile fails” posts are a good thing – it means people are actually using agile. 🙂
Don’t agree? The comments are there for a reason..
Pair programming is often recommended as one of agile techniques that help improve productivity, team chemistry and code quality. Unfortunately I have never seen it actually work the way it is described – two people sharing a desktop writing some code full time together. There is always something that prevents this happening.
For instance, developer A is very quick, write-it-first-than-think-about-it style. Developer B is more of the ok-lets-think-twice-before-we-press-a-button style. Both are good in their own way, each one can develop the feature in question in more or less same time and quality. Try to combine them together? Not so good. If B drives, A becomes bored and loses interest quickly. If A drives, B gets nervous and loses track of what’s going on.
If you say, well, just organize the team so that the people have same style, I am not going to agree with you. 🙂
Diversity is good, as long as people are willing to work together (very important), different skill sets and styles are useful – some task are better suited for one or the other. And besides even if both developers were twins, there are still a bunch of factors that make pair programming difficult – outside interference, workstations not optimized for pairing etc.
So instead of “classic” pair programming we do a “limited” version of it. Well, the goal is to keep the collective ownership on the code (or at least on the tasks that do require it – not all bug fixes need to be looked at by two people for example). How it works? It’s very simple. Each “important” task is assigned two developers that are responsible for it – but we do not tell them that they have to work in pairs. Instead they are free to decide themselves how they want to split work. (BTW, this really emphasizes bottom-up style of agile). Some larger tasks may have even more people assigned to it.
So what follows is that the mini-team will some brainstorming together about the task AND the best way to accomplish it. After the main details are discusses and agreed they will usually split the actual mini-tasks and work solo and then integrate them together. For us this gives all the benefits of pair programming without the drawbacks and without the need to force people to “sit together”.
What do you think? Have you participated in long term pair programming teams? Or similar approach to ours is used? Anything else that can be done to improve it? Use the comments 🙂
Classic SCRUM process defines two types of backlogs.
Product backlog – a list of all features and user stories that are planned to be included in the product.
Sprint backlog – a list of tasks to be completed during the current sprint.
There are a number of important differences between the two. First, there is only one product backlog but there are many sprint backlogs because each has sprint has it’s own. Second, product backlog is usually very “fluid” and open to change (as it should be) while sprint backlogs are extremely static – once defined they are supposed to stay the same. I was lead to believe that changing sprint backlog on the fly can be considered a type of “smell” – in other words an indication of bad practice.
This “duality” is something I have been thinking about lately. Clearly there are some benefits of having static sprint backlog, such as team commitment, “protection” against outside pressures and so on. However the static nature of sprint backlog means that we have to plan all our work a month in advance with good precision (we use month long sprints) and that is something we were unable to do very well even though we are practicing SCRUM for almost a year now.
Perhaps this is specific for our team and project domain but planning a month ahead is always hard for us. We usually have 2 types of user stories: a few “big new feature” ones which are usually very hard to predict correctly and a very large number of “enhancements” which are easy to predict but hard to manage because there are really many of them. Splitting of big user stories into tasks is also rarely possible in advance, but only after we start working a little on them, but because sprint backlog is static we do not bother to update it with smaller tasks.
Because of all of this I have been thinking of replacing static sprint backlogs with more dynamic sprint “queue”. This queue will have a small number of “slots” each filled with a task. Every time a team member completes some task he will be able to pull a new one from the queue (but not from the product backlog). The queue will be refilled once in a while (once a week?) by product owner or scrum master during the daily sync meeting.
I believe this method will really simplify the things. Iteration planning meetings will be shorter and primarily used for high level discussions. Task estimations will be done during queue “refresh” so they will be much more accurate because they will be closer to implementation time. Task and bug management also becomes much simpler because there is no need to plan ahead much. On the other hand we will be able to keep a monthly iteration cycle.
Why not just have a shorter iterations? Well, it is also an option but for us the choice of month long iteration is based on some external factors (such as monthly demo) so I think the backlogs are much easier to change. Other teams may choose differently.