Take away’s from this session:
- Understand what is Agile Software Development
- Origins of Scrum
- What is Scrum?
- Who is using Scrum
- What can’t be solved by Scrum
- A brief overview of Scrum Framework
Take away’s from this session:
One of my favorite YouTube videos about transition the project managers have to make from being a project manager to Agile Coach is from Lyassa. Here are the videos if you have not seen them already:
Lyssa, compiles some excellent points from general beliefs and principles that most Agile Coaches adhere to, primarily:
I will try and gorge on other material on the Internet for the same as this is an important topic to discuss.
I have seen many a people say that Scrum is not Agile in strictest sense. Why? Because it forces down processes on people rather than have people fix the process. In fact in much of the CSM classes, you are told this is something you can tweak and this is something you can not. For instance, you do need a Sprint Planning, you need to do a Sprint Review and Retrospective and a Daily Scrum, have a Product Owner, Scrum Master and a Team. I guess you can omit the last part because you will need it anyways. You can not choose not to have a Scrum Master or a Product Owner or worse not do Daily Scrum. What if a team does not want to? Well the simple answer seems to be, you don’t have to do Scrum by the book. It pays to do it by the book till you get used to it and once you get used to it you can start questioning the wisdom of the roles and practices. There is nothing, that says you can not question the wisdom at the start itself – however, if you question after trying something out a hundred percent, you might be able to question better [or at least that's what I think and I can be wrong on this].
My take on this and something I tell the teams I deliver sessions to is : Agile is like a religion. You can be religious without following “a” religion [like Hinduism or Christianity]. But following Hinduism or Christianity can be a good starting point to be religious for some [but not all]. Further, you can be Hindu and Christian at the same time [many Hindus study in Convent Schools and celebrate Christmas]. In addition, you can never be more Hindu or Christian than another Hindu or Christian. Both of you are at your own levels. Similarly, Scrum can be a very good starting point and you can mix it with some of XP or less of XP. Also, unlike rabid Scrummists, I also suggest that you can never be doing more Scrum or less Scrum than others. Tests like the Nokia Test for Scrum are a good reference and starting point but the team should be able to come up with their own tests and revise it often.
Just like having fanatics in a religion does not make a religion bad, having a group of aggressive consultants market Agile, does not mean Agile in itself is bad. Similarly, you often hear : “Religion is always private and something that you share with God, you don’t want others to preach it down.” The problem with this viewpoint is that it is your viewpoint. You might not want priests to help you connect with the God, but others might. Similarly, much of Agile might be common sense but getting this common sense across might need an external consultant. This is what blog posts like The Agile Disease, Scrum fails to come to grips with Human Psycology and Technology is already Extreme get wrong.
I always tell whom ever I talk to Agile about, Agile is not a destination, its a journey. Take Scrum, XP, and everything else as milestones that help you savor and experience different aspects of Agile. Eventually your own journey could help you define and discover, what you think they [Agile, Scrum, XP or <insert your framework name here>] should contain.
Various authors have tried to analyze and present resources for Agile Adoption. Two of the recent ones are, Brad Appleton and Vikas Hazrati. As per a survey by Scott Ambler on Dr. Dobb, in 2008, 69% of some 600 respondents still are doing Agile. I don’t know whether to trust this number or not. 600 plus is just too small a sample size of the worldwide IT industry [its probably too small for even Silicon Valley]. InfoQ has actually concluded on the Scrum Adoption in China based on a survey of 05 people. Compared to this the Forrester Report on Agile Adoption seems better provided you assume that Forrester has on their client list a fair representation of IT industry. You can probably hazard a guess from Analysts Survey of Customer that found customers happy, that if customers are happy, the trend will grow. You have some niche groups like Agile Philly, which seem to suggest a lot of companies doing Agile in one area. You know that Scandinavian Countries are sold on Scrum. Further, back in November, 2005 Forrester Research has released the following report: Corporate IT Leads The Second Wave Of Agile Adoption, excerpt:
“Agile software development processes are in use at 14% of North American and European enterprises, and another 19% of enterprises are either interested in adopting Agile or already planning to do so. Early adopters of Agile processes were primarily small high-tech product companies. But a second wave of adoption is now underway, with enterprise IT shops taking the lead. These shops are turning to Agile processes to cut time-to-market, improve quality, and strengthen their relationships with business stakeholders. But as awareness of Agile processes grows, so does confusion about what it really means to go Agile.“
So overall, the growth seems nice, even if its not proven by a proper scientific study [or one that I am aware of]. However, what these reports conceal is that within the adoption itself you have to question how many of them are actually implementing Agile. Almost 80% of all the teams surveyed so far, have not passed even Level 1 of Nokia Test for Scrum. That tells me, there is a lot of talking, and little execution or if there is a widespread usage then its all in stealth mode [which I don't think is true]. My own little experience also suggests that there is a lot of talk rather than walk the talk. There is also a lot of misconception and misinformation. I have conducted trainings for 03 MNC’s who have material out in public domain on Scrum and Agile in their organizations. In one large electronic firm, the managers were still giving the estimates, breaking down the tasks and Scrum Master was a team member too. In a large service based organization in India, the Scrum Master was in United States while the team was in India. In yet another large consulting and service organization, the task breakdown was done only by select members of the team. There is a lot of training and coaching happening but it seems like the coaches and trainers are just talking and not confronting the management or default culture or organizations [to not annoy them?] and the management are just conducting these trainings for the heck of it?
In his blog on Product Management, Saeed proposes a fifth element to the Agile Manifesto:
Business Alignment over Engineering Features
His argument is that developers, testers and even managers treat each feature equally without worrying about how the business makes money. There were some interesting responses to this:
1. Jelena said that this is already contained in the Principles “Business people and developers must work together daily throughout the project”, and also can be filed under “Customer collaboration over contract negotiation” element of the Agile manifesto. She also goes on to say that sometimes engineering excellence is more important.
2. Others illustrated how product management and development can never reconcile.
I don’t think it is needed to have another element to the manifesto at all. As Jelena said, it is already contained in the principles and also in the elements. If a Product Owner can not make efficient decisions and guide the roadmap, then the team can’t do anything. For instance, in the firm I work with currently, the Product Managers and Development Managers blend so effortlessely that you wont even notice, who is who. This closely aligns the business with the development. We prioritize, reprioritize vigorously and we make decisions collectively – sometimes development helps us make better decisions [what if we just made a single HTML page rather than all dynamic feature that you want and will take time] and sometimes businesses help development make better decisions [we need a guarantee that whatever was working before is working in future].
In essence, elements basically highlighted the importance of where our focus should be. Business Alignment over Engineering Features places a lot more emphasis on Business Alignment and takes the focus away from Engineering Features. This is also partly wrong – engineering features and excellence in itself is also sometimes desirable.
I talked about my presentation at Agile Chandigarh Inaugural Event. I presented on the topic “Common Myths about Agile Software Development.” This is a recurring topic, and many discussions you see on the Agile Groups, are basically centered around these myths. Hence, I thought its interesting to revisit these myths. I remember, I had a hard time deciding which of the myths should be featured and which excluded. We did a random sample survey and even over a period of time, these are still some of common myths you encounter. You can watch the presentation on “Common Myths about Agile Software Development” to read more.
If you would like to embed, share the presentation, please follow the links below:
<object classid=”clsid:d27cdb6e-ae6d-11cf-96b8-444553540000″ codebase=”http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0″ width=”481″ height=”402″ id=”player” align=”middle”><param name=”allowScriptAccess” value=”always” /><param name=”allowfullscreen” value=”true” /> <param name=”movie” value=”http://www.wiziq.com/player.swf?u=http://www.wiziq.com&p=/Profiles/Content/Data/7351_633493579285468750_presentationinfo.xml&n=wiziq” /><embed src=”http://www.wiziq.com/player.swf?u=http://www.wiziq.com&p=/Profiles/Content/Data/7351_633493579285468750_presentationinfo.xml&n=wiziq” width=”481″ height=”402″ name=”player” align=”middle” allowscriptaccess=”always” allowfullscreen=”true” swliveconnect=”true” type=”application/x-shockwave-flash” pluginspage=”http://www.macromedia.com/go/getflashplayer” ></embed></object>
I never thought that a discussion on prioritization would make me discuss the increasing concept of post-agile in Agile community. There are 5,170,000 results for post-agile on Google alone and that tells you how high this figures in the discussions. There is even a post-agile manifesto and a website too [www.postagilism.com]. The manifesto says:
1. If it works, it works
2. If it seems to work, it probably works
3. If it seems to work, it probably works and it might work again
4. If it seems to work, it probably works and it might work again [cogito ergo sum - although admittedly this is an assumption]
All of this looks nice, but does not really explain what it is. Most of this movement comes from assumptions like “Agile movement is being hijacked by Scrum and XP guys”, “There is a lot of hype about Agile”, “People are processizing Agile too much” and “You can’t know if you are doing Agile well enough or not”].
You can read more on some of these blogs:
At the heart of all that I have read about post-Agile is “Going with the Flow and Pull based Organization”. There is sometimes severe resistance to process and practices and emphasis on choosing the right team and working on their dynamics, assuming that as long as the latter is taken care of, everything will go right. I don’t disagree on this but how see the post-Agile movement is an extreme version of Agile. Hence, if software process were like a pendulum, it would swing between post-Agilists and heavy methodologists. Agile is probably somewhere in between bringing the best of both worlds and the only rest point for the pendulum. Most of what post-Agilisits say is already covered under Agile [or agile] manifesto. The heart of Agile is inspection and adaptation. If that means, doing away with process altogether and having a streamlined flow – then so be it.
P.S. In my current organization, we work in a fashion that would be akin to post-Agile, although I would want it be what would be rather Agile Let’s see how going with the flow or pull based organization can help you achieve a different way of prioritization of tasks in the next post.
One of the themes which I get asked most often is, how to calculate how much time is available in a given sprint and to know if someone is overcommitted or undercommitted during a sprint. And its not Scrum Masters, but teams asking this question.
Well lets say the team comprises of four members – Anand, Lee, Sam and Pamela. In addition, there are two part time members – Rose and Kate. We assume there is a two week sprint. A 4 hour sprint planning and 4 hour sprint review/ retrospective means one day of the two week sprint goes in ceremonies. The first step is to ensure every one is available for these ceremonies. Once they are there, you can write down each of the coming working days and check for half day leaves/ full day leaves or other engagements for everyone. You can then note down effective hours everyone has available and do the total. Doing this every sprint can give a “very rough” mapping between hours available and story points burned. Why this approach works is because we are not mapping hours spent and story points burned. As hours available and story points burned are suitably high level abstractions of estimates and planning – this gives “rough insight” for a team to plan.
Another variant of this approach is to try checking how many quarter days each member has available. You don’t know how many hours in quarter days has one available, just how many quarter days are there [in all there are 4 quater days a day]. You can then map the quarter days with story points burned. Similarly, half day approach can be tried.
Both the above approaches are supposed to be used only if team members would want to use them as a rough insight into how much work to plan. This would be probably useful also if the team adds or removes members often, and some sort of rough guidance for the team on time available and story points to be picked up is helpful.
As discussed in the previous posts on potentially shippable code, its not just the iterative and incremental development that sets Agile apart from other development frameworks. In part it is its focus on getting to potentially shippable code at the end of each sprint but also the values it emphasizes. These values are best captured in what is called Agile Manifesto. The signatories of the manifesto include Kent Beck [creator of jUnit and originator of concept of Design Patterns], Martin Fowler [originator of the concept of Refactoring], Dave Thomas [wrote the landmark book on Agile Development with Rails], Ken Schwaber [co-founder of SCRUM] and Brian Marick [world renowned testing expert]. Agile Manifesto states that:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
The principles behind Agile Manifesto were as follows:
In the last post, we discussed how not to meet potentially shippable code. However, we never really addressed the question as to why is the potentially shippable code that important anyways. It is often argued that the relentless focus on getting to potentially shippable code, is what sets Agile apart from other incremental and iterative processes. This is partly correct. Partly, because there are certain values which Agile stands for and if those are not used for the development, you are not really doing Agile.
Potentially shippable code as discussed in the previous post is always just one sprint away from shipping. Why this is important is because:
One of the tests of whether teams are doing Scrum in Nokia, include reference to “do you provide potentially shippable code at the end of the sprint?”. I have found focus on potentially shippable code really good way to help provide focus for all concerned on product success.