Learn Software Development

Engineering Practices Not Taken Care of by Scrum – Some details

ashish — Tue, 31 Aug 2010 19:07:46 +0000

Scrum never talks about engineering practices which is a good thing but this sometimes lands teams into trouble. The teams not only adopt the Scrum practices but also the principles which makes their progress sluggish and results in the code base being in a mess. This is a situation which is present in most of the cases where a failure has happened and the teams state that they have been implementing Scrum. Given that it is far easier to blame a process rather than do the necessary hard introspection, teams blame Scrum about not being able to provide engineering practices but they miss the entire point; Scrum is not about engineering practices, it’s about management. Engineering practices are whole and sole responsibility of the teams. Scrum only creates organized teams. They organize themselves, they organize their tools and they organize their engineering practices, and Scrum then opens up the entire process in terms of more information that teams have to learn to handle, and use to improve the way that they do things.
Consider some examples: The definition of Done (DoD) is defined by the development team. The criteria for done can be different for different teams; some teams might consider a piece done once the code has been reviewed others may consider is done only then functional tests are carried out and still others may call it done when the documentation is also done. It becomes necessary to keep an optimal level of done so that technical debt does not come into picture too much. And what is ‘technical debt’ ? Well, the concept of technical debt states that while adding a piece of functionality, two different approaches can be used. The first one is doing a quick job and the other one is a clean design. The quick design would mostly be messy, and one of the bigger problems is that making further changes become harder in future. So doing things in a quick and dirty way, results in technical debt which in turn requires extra effort to be put when future development is done. Doing a quick job is useful when you need to meet a deadline and can afford the extra effort later. However, you need to be sure that this is the approach you want to take, and not be surprised at the extra effort needed to be put in later.
The main difference between classical approach (Waterfall, etc) and scrum approach of development is that in scrum developers have more freedom to define level of done and amount of work to be done. They decide on the User stories to work in each of the sprint (through the estimation, although the priority comes from the Product Owner). Developers who do not use professional practices fail; but they fail independently of the processes used; blaming the processes of Scrum is convenient, but some inspection by external parties can easily reveal problems in the way that they do things.
There is sometimes a talk about too much quality being pumped into the product. Sometimes it may be a cause of concern for the owner if the team takes too much time for quality. The concept of iron triangle comes into picture here. This concepts states that Scope (features, functionalities etc.) , Resources (cost) and Schedule (time) can be considered to be three vertices of a triangle and Quality is the area enclosed by this triangle. Different groups have different priorities: users want more scope, senior management wants cut in time, financial team wants cut in budget and development team wants more quality. The end aim is to strike a balance into all the four entities. Scrum sets resources and time and lets developers decide the scope. Speed is scope/time and it’s a measure of output. If the product owner wants a higher velocity then he must work towards removing impediments; but dropping of engineering practices is not a solution. Compromise in quality is a slippery slope best avoided, and can result in so many problems later that any benefits from reducing quality are to be avoided. Consider advising a stuntman to drop safety equipment; he will never and so should be the case with developers (and even more so with the people responsible for the quality of the features and the product).

Slicing For Better Results – Ready User Stories

ashish — Mon, 30 Aug 2010 18:21:43 +0000

The biggest issue faced in product development is effective communication between the team of the developers and the customer. The needs of the ever evolving products keep changing. Estimation of work, keeping track of the requirements, knowing the conditions of satisfaction, delivering on time even as new requirements surface in are some of the challenges faced. The biggest issue is bulky requirements which are not easy to understand and are not prioritized well enough to be comprehended by the development team. The best way to solve this is by applying splitting techniques to break the user stories into smaller easily understandable and prioritized fragments.
An optimum slicing technique would be the one that can be used in all problem domains. The first step towards slicing is Ready User Stories. These are small, understandable, valuable user stories. A ready story is essentially needed for estimation, planning, commitment and delivery. The ideal time by which the ready story should be in place is just before planning as a part of the backlog grooming. The team of developers should collaborate with the product owner to groom the backlog for changing requirements and prepare user stories for upcoming cycles.
The process of slicing includes an overall pattern called expand and contract. In the expand phase the product owner first elaborates all the possible options detailing about each of the options. Then in the contract phase team and the product owner sit together and contract the options based on their values. The result is a crisp story ready for development. For the expansion phase the owner need to analyze who the user is, actions needed to meet user’s goal, data objects used, business rules to be applied, interfaces needed, quality issues etc. In the contract phase looking at rational criteria like return on investment, feasibility option, risk etc. the product owner along with development team selects options. Through the process the product owner gets to know how about the efforts and risks for implementation in turn making him more aware of the technical aspects of the development process. The development team also learns about the options and the requirements. For example assuming that the users for the product are Individual Buyers, Corporate Buyers, Club Member Buyer and Employee Buyer; ask the product owner to prioritize the user role type options by determining which role has the highest business value for the next iteration. Next explore the possible states.
Assuming the options for individual buyers are New, Existing, Anonymous and Archived. Again the contraction of the options has to be done. Further assuming that the user priority is anonymous and further action options are Verify Cost, Calculate Tax, Calculate Total Amount, Apply Discount, Apply Wrapping Fee, Secure Payment and Generate Receipt. Then determine the minimum options for the next delivery and defer all the infrequent ones for future deliveries. Similar process is then followed for all the further options. The slicing should be done the “just enough, just in time” way. This is a fast, efficient, repeatable technique that streamlines planning and jointly engages the customer and team in optimizing value.

Screwing Up Software Development – a sarcastic look at how projects fail

ashish — Sun, 29 Aug 2010 18:30:07 +0000

We all complain about potholes on the city roads, but when it comes to software development, the process sometimes becomes so monotonous that you long to have potholes and speed breakers in the process. So, what do you do when you want a bumpy ride? You introduce the bumps yourself! So if you mangers are reading it and you find out that one of the developers is introducing potholes go easy on him, he is just making is work challenging. Statutory warning for developers using Scrum: Implementing the below mentioned techniques might lead to you being sacked from your job, but for the carefree go on and implement it.
Starting off with the ScrumMaster who is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influencing. What is to be kept in mind is that he is neither a tech guru nor does he know Scrum. He has no contact with the customer and lacks test environment so he won’t present too many hurdles in your way. Starting off with your mission, don’t have a default Definition of Done (DOD) and even if you have one don’t bother to obey it. Start to assume that if the code is acceptance tested, has release notes written and there is no increased technical debt then you haven’t messed up with the code base. Don’t have Sprint Retrospective, even if you have one don’t list improvements, even if the improvements are listed don’t execute them and even if the improvements are executed don’t follow them up. Have unwanted people at the meeting. Don’t have a set pace of work keep changing your pace from time to time.
Another aspect of the team which can be attacked is team commitment. Put pressure on the team. Don’t track and learn, try over committing or under committing every time. Let the technical debt pile up and continue ignoring it. Stick to your own role and don’t help others in the team. Take care of only your personal backlogs and implement all stories in parallel. Another critical feature of Scrum is Product backlog. It is a high level document for the entire project and contains backlog items such as: broad description of all the features required, wish-list items, etc. prioritized by business value. It is open and editable by anyone and contains rough estimates of both business value and development effort.
It is owned by the product owner. For defeating its purpose fill the product backlog with never ending stories. Product owner can help by not prioritizing and not maintaining it properly. Shy away from merging, seldom integrate and try to evade responsibility. Finally make Sprint backlog too complicated. It is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks with the level of detail that the whole team understands what to do. For our mission don’t use it during daily Scrum, don’t update it regularly and last but not the least don’t prepare a burndown. Hope the above techniques add some spice to your work life. All the best!

Low Hit Ratio for Scrum – needs work from the team working on this

ashish — Mon, 23 Aug 2010 18:49:54 +0000

Scrum is an iterative, incremental framework for project management and agile software development. Rather than full process or methodology, it is a framework. Instead of providing complete, detailed description of how everything is to be done on the project, much is left to the team. This is done because the team will best know how to solve its problem. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as general project/program management approach.
The Scrum approach is sometimes compared to rugby, where the whole team tries to go the distance as a unit, passing the ball back and forth. The Scrum Team is self-organizing as there is no overall team leader which decides which person will do which task or how a problem will be solved. The team is cross functional so that everyone necessary to take a feature from idea to implementation is involved. Scrum projects make progress in a series of sprints, which are timed iterations no more than a month. At the start of the sprint, team members commit to delivering some number of features that were listed on the project’s product backlog. At the end of the sprint testing is done and the features are then integrated into the product. At the end of the sprint a sprint review is conducted and feedbacks provided influence the next sprint.
The co-developer of Scrum Ken Schwaber once said, “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it”. He also said that Scrum exposes every inadequacy or dysfunction within the product and system developed practices but many organizations change Scrum to accommodate the deficiencies instead of solving them. But contrary to this comment, it is often seen that the dysfunction exposed by Scrum is often not understood by the teams properly. Whenever dysfunctionality appears it is assumed that the problem is with the team because it is the American way that the people having the problems can pull themselves out of their problems.
It is more often the case that the root cause of blocked flow is somewhere else in the organization even though it is showing at the team level. Hence if teams start with Scrum arbitrarily the companies might not get the values they seek because they are not solving the real problem. And the problems in other areas are typically caused by violating lean principles which most people are not familiar of. The reason for people not being aware of the lean principles is that they are not discussed by most Agile consultants because it is believed that for success with Scrum you don’t need lean. Therefore the reason people accommodate the problems is that they really don’t know how to solve them. So the teams attempting to do Scrum from a team perspective should expect a success rate of only 25% because only part of the time the team will be on the main challenge and it requires a bigger view to view this.

Why does Scrum fail – the project was not actually Scrum

ashish — Wed, 04 Aug 2010 18:52:07 +0000

This is part of a series of posts that I am writing about, that deal with why Scrum projects can fail. It could be a variety of reasons, ranging from team resistance, to wrong policies, to bad management. In this post, I will deal with yet another reason as to why a Scrum project could fail. This is probably the most simple reason, yet can be difficult to determine. These are typically projects that are claimed to be Scrum, but are not actually Scrum. And there can be multiple such processes that the team could claim to follow, but the basic reasons for failure in a number of such cases would be that the team thought that they were doing Scrum, but were missing out on many of the core processes, which eventually led to failure. Some of these cases could be:
- The team decides to have a daily stand-up meeting, and considers that they are doing Scrum. However, they would find over a period of time that the stand-up meeting does not really lead to many advantages, and start deferring the meeting with people cribbing about the meetings appearing to be a waste of time. The reason would mostly be that the meetings were being used for status, or were not succint enough, or did not focus on the past day / present day / impediments only approach, and turned off people due to the time lost. Just meeting daily and talking about issues does not make a Daily Scrum meeting.
- One of the ways that people start to believe that they are following Scrum is when they believe that the Scrum team is empowered to take decisions, but when you get down to basics, that is fiction. To allow the team to be empowered enough to take decisions after thinking through the implications is something that is easy to state, and difficult to actually implement. In a number of cases, the managers of the various teams get involved in the decision making, and more critically, do it in such a way that the Scrum team is not actually involved. This makes the team members start doubting the actual concept of the empowerment that they were promised during training sessions.
- I have seen numerous cases, where when a team is in trouble, they start meeting daily for 10-15 minutes to gather around and discuss status, and then later call these as Scrum meetings. This is certainly not Scrum, those are typically status meetings run by some manager, and is there to ensure that the team is working according to a desired game plan, but just a short meeting daily does not make it Scrum.
- In other cases, teams cannot handle the openness that Scrum data as well as retrospective meetings entail, and start trying to limit the scope of discussion and modulate the discussion and data analysis rather than working through the data in order to figure out exactly where the team is. This can lead to significant deviations from the openness desired from a Scrum process.