Practical Report: CMMI Measurements and Analysis based on Agile (Scrum) Method

Software industry is one of the most empirical industries due to its high dependence on technology and people. Each software company adopts a specific development methodology, and furthermore seeks to build a system for its process improvement by adopting one or more Software Process Improvement (SPI) models. CMMI is a process framework which is widely adopted by software and systems development companies, while Scrum is one of the more recent project management agile method whose adoption is growing rapidly. CMMI is basically a process improvement framework which provides a set of processes for software and system development management, Scrum can be thought of as an iterative project management framework for development activities, CMMI has a wider scope and different aims to those of Scrum and covers production support, maintenance, product implementation and application transition type projects as well.
Scrum and other agile methods have clearly appeared in 2001, This paper shows how to implement the Measurements and Analysis (M&A) process area of CMMI model and clarify how M&A can be achieved in the agile (Scrum) organization. Most of the promising objectives of any software development method or process are delivering working software on time, quality and budget. Software Engineering Institute (SEI) has paid a lot of efforts to mostly satisfy these objectives in its process improvement models, and lately CMMI version 1.2 has been released. Nevertheless, the world becomes convinced with adding another objective, which is delivering a business value to the customer. Along the years, software engineers have proposed several methodologies
Agile is the most known and latest proposed development method that can achieve this objective beside the other fore mentioned objectives.
Our objective in an agile environment is not to do software measurement. We must learn to build reliable software measurement process based on valid software measurement tools. If we try to do too much too soon, we will likely fail. Basically, software engineering measurement is not a resource issue; it is a commitment issue. The bottom line is that all the usable measures from practicing Scrum on a project could be used to address the practices of M&A process area. Infact, the alignment of these measures to the information needs is very visible due to the very nature of “value-based” focus of the scrum method. In our research, we found that there need not be any additional measures that are required to be “invented” to fulfill the M&A goals from CMMI model. Usage of existing ones is enough and we will share those mappings and arguments with you for your application and subsequent extension to other process areas in the model. We are also going to share our learnings from carrying out these discussions/learning events with you.

Find paper abstract in CMMI 9th Technology Conference and User Group, National Defense and Industrial Association
http://proceedings.ndia.org/0110/9225.pdf

Download the full paper, if you are interested, please send to aamahdys@gmail.com and I will reply with the paper attached.

The Role of the Agile Coach

One of the new roles introduced by Agile software development is that of the team Coach. Until Agile came along coaches were confined to the executive suite or the sports field. As with any new role it takes a while before it is fully understood and scoped.Agile teams can, and do, exist without the Coach role being filled but such teams do not necessarily achieve peak performance. Reports from Yahoo* suggests that coaches can make a significant contribution. In this study Scrum teams without coaching support increased their productivity by 35%, while those with Coach support recorded 300% or greater improvement.
What then is the Coach’s role? And what does a Coach do?
For some people the title Agile Coach is self-descriptive but for others it leaves the questioner none the wiser. So let me offer a definition: an Agile Coach help a teams or individual adopt and improve Agile methods and practice. A Coach helps people rethink and change the way they go about development.
Trainer and consultant
The Coach role is part embedded trainer, part consultant – specifically an advisor. Even the best Agile training courses cannot cover every detail or eventuality a team will encounter. The Coach is there to continue the training after the formal classes are over.Having an onsite Coach will help team members put their training into action. Too often people attend training, think it’s good stuff, and then fail to incorporate their new learning into their daily work. This is particularly true when the organization sends mixed messages about change.The Coach also helps teams apply Agile and Lean thinking to the specific environment and impediments they face. Working as an advisor the Coach can help the team adapt the methodology to their environment, and help the team challenge the existing environment.Taken together these two sides make the Coach into an effective change agent - someone who is both motivating change and making it happen. That an organization is prepared to spend money on a Coach demonstrates they are serious about making the change happen.So as well as helping the team execute the Agile vision the Coach may also help motivate the team to that vision. The Coach does this by painting a picture of how the Agile world works by telling stories and providing explanations.
Three types of Coach
While every Agile Coach brings their own approach to an assignment there are broadly three types of Coach. The first is technical, such a Coach works mainly with those cutting code and sometimes becomes fully integrated with the developers. Technical coaches are likely to be found pairing with developers to help them apply test driven development, support developers in refactoring work, help improve the continuous integration system or other activities that are close to the code.Technical coaches are experts in what they do, they aim to both transfer their knowledge and enthuse team members to try new approaches and techniques.The second type of Coach is again an expert who aims to transfer their knowledge however the focus is not on technology but on process, management and requirements. Coaches like myself work with project managers, line managers, business analysts, product managers and others who are responsible for making the work happen.Rather than working at the code-face coaching tends to happen in meetings and in one-on-one sessions. There is a greater focus on facilitating events that help create change and improvement.For example, in addition to moderating stand-up meetings and planning meetings, I normally run retrospectives and “future-spectives”. A future-spective is an event which applies many of the same ideas and techniques as a retrospective but is used to kick-off a new project or Agile transition.When working with managers there is more to coaching than simply knowledge transfer. It is much more about helping people rethink their inbuilt assumptions and mental models. Many managers have experienced career success with other development modes so may perceive Agile as a threat. Here coaching gives way to the third type.The third type of Coach may work across everyone in the team but mostly finds himself working with managers and analysts. In this mode the Coach drops the expert persona and focuses instead on helping individuals and teams solve their own problems. To do this the Coach takes on a non-directive approach. When working as an expert authority the Coach is providing direct advice and recommendations. This is known as directive coaching. In the non-directive mode the Coach may – or may not – be an expert in the field but they assume the coachee is the expert and the Coach helps facilitate their learning.While directive coaching is often found in sports teams the non-directive approach is used by coaches who help business leaders. This approach is set out in books such as Coaching for Performance** and Effective Coaching*** and anyone thinking about embarking on this approach is well advised to read at least one.The diversity of coaching roles makes it difficult for one person to fill all. A technical expert will find it difficult to switch to a non-directive mode and team members may be confused when an expert starts throwing questions back at them. Even if one individual can cover all bases on all but the smallest projects there is unlikely to be enough time to do each role justice.
Longevity of coaching
However a Coach works, and whatever approach they take they the Coach needs to avoid creating a learned dependency. This happens when the team comes to depend on the Coach, without the Coach the team fall back to their old ways. Coaches need to be able to withdraw when the time is right and let the team continue.While many companies will have their own coaches on staff and some will work with teams day-in, day-out for months or even years, there is a lot to be said for using external coaches and limiting the period of coaching.While internal coaches will start with the advantage of knowing the team and domain, external coaches benefit from bringing a fresh mind and new perspective. This allows them to challenge assumptions more easily and suggest alternative approaches.Some coaching activities – such as running retrospectives – can become stale and formulaic over time. Changing the facilitator can inject energy and new ideas.
Scrum Master or Coach?
As an Agile Coach I am frequently asked “What is the difference between a Coach and a Scrum Master?” Indeed, there may be very little difference if a Scrum Master decides to play the role from a coaching perspective. However this is not always the case, some organizations see Scrum Masters as thinly disguised Project Managers. In such cases the difference between Coach and Scrum Master is wide.There are perhaps two main differences between the Scrum Master and Agile Coach role. In Scrum the Master is tasked with ensuring the team follows the Scrum process and rules. An Agile coaches remit is somewhat wider with a greater emphasis on the change agenda.As such, the second difference is one of duration. All Scrum teams should have a Scrum Master who works with the team in every sprint and stays with the team for the duration of the work. An Agile Coach may stay with a team but they may also move on, or they may stand back over time.On an assignment last year I coached several teams at one company. Initially I started with some training and by walking each team through the Agile ceremonies – planning, daily meetings, retrospectives, etc. As the teams became more familiar with the activities I reduced my involvement and allowed team members to take over.Again, this approach casts the Coach as change agent. It may be that teams need different coaches at different stages of their development: A technical coach to help the developers master TDD; a second Coach to lead the team through early adoption and a third to refine the processes and practices later.
Conclusion
Much of the Coach’s work is about changing individuals’ mindsets, the mental models and short-cuts which they have build up over years. As my fellow Coach Niels Malotaux put it recently “Coaching is about resetting people’s intuition.”There are hundreds, even thousands, of small decisions made every day during software development. These decisions are based on people’s mental models of how development works – or how it doesn’t work. Part of the Coach’s role is to help people unlearn many of these models and relearn models based on Agile values. Cumulatively these many small decisions are more important than the few big decisions made occasionally. By definition big decisions aren’t made that often and you usually know they are being made but small ones are made without thinking. It is no use switching to Agile if you keep making the small decisions based on some other model.The architect Mies van der Rohe once said “God is in the detail” and so it is with Agile: “Agility is in the detail.” It is the small decisions that can’t be seen in advance that often derail work. It’s the Coach’s job to help spot the small decisions and ensure they Agile principles are applied.Part of the reason I prefer working as a Coach with a team rather than as a Trainer is because you see the change play out over time. Yes I deliver training but when I’m gone do people use it? When I’m there as a Coach I walk people through the changes, the details and I see the change happen.

References:
Rolling Out Agile in a Large Enterprise, International Conference on Software System, Hawaii, 2008, http://www2.computer.org/portal/web/csdl/doi/10.1109/HICSS.2008.382
Coaching for Performance, John Whitmore, 1992
Effective Coaching, Myles Downey, 1999

Scrum model in one page!

Source: http://alistair.cockburn.us/JDKrise+Scrum+laid+out

Scaling Agile Development Via Architecture

Every system has an architecture, even systems developed using agile methodologies. Whether you attempt to define that architecture up front in detail or whether it emerges over time is up to you. My experience is that most agile teams follow a strategy somewhere between these two extremes, one that involves investing a bit of time up front to think through the "big issues" but which addresses the details on a just-in-time (JIT) basis. That strategy, combined with proving your architectural ideas as soon as possible through working code, results in a very agile and low-risk approach to system architecture. This article summarizes a collection of strategies for addressing architectural concerns on agile projects and discusses how such strategies can be applied to scale agile methods to large development efforts.

Agile Architecture Strategies

Many of the architectural strategies listed below describe trade-offs; the implication is that you must tailor an approach which meets your unique situation. These strategies are:

1. Model with others. Modeling, architectural or otherwise, is best performed by two or more people working together collaboratively. By working collaboratively you will create a higher quality product, will develop a shared vision, and will learn from one another.
   


2. Focus on collaboration over documentation. {sidebar id=1} "Agile architects" are active members of development teams who also write software -- they are not simply people who document their vision and hand it off to developers. This greatly increases the chance that the system reflects the desired architecture and that the architectural vision reflects the realities faced by the team. Note that there may still be some documentation, but that's a secondary effort.
   


3. Prove it with code. Everything looks good on a whiteboard, or in a PowerPoint slide deck, or in a modeling tool. You have no idea if your architecture actually works until you try to implement and test it. The implication is that you should prove that your architecture works, something that Extreme Programming (XP) calls spiking and the Rational Unified Process (RUP) calls architectural prototyping. Sometimes you will discover that your original approach doesn't work or how your approach actually works (instead of how you thought it would work). Proving your architecture with code helps to reduce risk to your project because you quickly discover whether your approach is feasible; the longer you go without coding the greater at risk you are.
4. Keep it simple. Agile software developers model, but we often do it in ways which are very different than traditionalists. We create sketches, we capture requirements in index cards, we create abstract user interface models using paper and sticky notes, we write acceptance tests which we consider to be requirements, and we write unit tests for our detailed design efforts.
5. Use the simplest tools. The vast majority of agile developers create free form diagrams, often simple sketches on a whiteboard which overview how we intend to build the system. These diagrams evolve over time. Teams lucky enough to have dedicated whiteboard space will evolve their sketches appropriately as the project progresses. Sometimes the diagrams are captured and cleaned up using a drawing tool or a software-based modeling tool, and we may even generate new code from the models or use the tools to visualize existing code. Sometimes the simplest tool for the situation at hand is a whiteboard; sometimes you need a tool that is a bit more complex.
6. Think through the big issues up front. Figure 1 depicts the Agile Model Driven Development (AMDD) lifecycle. It indicates that initial architectural modeling is typically performed during "iteration 0," the initial inception phase of your project. For short projects (perhaps several weeks in length) you may do this work in the first few hours and for longer projects (perhaps on the order of twelve or more months) you may decide to invest a few days to do the initial architecture modeling.
7. Think through the details just in time. As you can see in Figure 1, you will often choose to "model storm" focused issues on a JIT basis. These model storming sessions are typically impromptu events: one project team member will ask another to model with him, typically lasting for five to ten minutes (it's rare to model storm for more than thirty minutes). The people get together, gather around a shared modeling tool (e.g., a whiteboard), explore the issue until they're satisfied that they understand it, then they continue on (often coding). It is desirable to take a JIT approach to identifying the details because the requirements are going to change over time anyway, you can ask better questions based on your greater domain knowledge later in the lifecycle, and your stakeholders provide better answers because they've seen working software delivered on a regular basis. Frankly, there's no rush - if you have the ability to model something today you will have that same ability tomorrow.
8. Allow good architectures to emerge over time. Although you can start with an architectural vision, or an architectural metaphor if you like, the fact is that the details will emerge as your system evolves to meet the changing needs of your stakeholders.
   
9. Travel light. Don't create a 50-page document when a five-page one will do. Don't create a five-page document when a diagram will do. Don't create a diagram when a metaphor will do. Remember Agile Modeling's They Ain't Gonna Read It (TAGRI) advice: close collaboration with others is a much more effective way to communicate your ideas than handing them documentation.
10. Have a few overview diagrams. Just because you're traveling light doesn't mean that there isn't any documentation at all. I typically strive to create one or more navigation diagrams, diagrams that present an overview of the "landscape" of the system. Just like a road map overviews the organization of a town, your navigation diagram(s) overviews the organization of your system.
11. Be flexible. The type of navigation diagram(s) that you create depends on the nature of the system that you are building. No one set of architectural views is right for every project. Instead, the nature of the project will help to define the types of views that you should consider creating.
12. Display models publicly. Your architectural diagrams should be prominently displayed where your team can see them and, better yet, update them. For a co-located team your best approach is to simply have dedicated whiteboard space for the team. Distributed teams find that a Wiki with snapshots of diagrams and point-form text works well.
13. Take a requirements-driven approach. Your architecture must be based on actual requirements put forth by your stakeholders, otherwise you are "hacking in the large."
    
    
    

Figure 1. The AMDD lifecycle.

Architecture Enables Scale
Although many software development projects are done by teams of less than ten people, some are much larger. Worse yet, your team may be spread out amongst multiple locations, time zones, and even organizations. To deal with the inherent complexities of managing such a team you will organize it into sub-teams, which in turn may be recursively organized into more sub-teams as required. These sub-teams will typically be responsible for developing one or more subsystems, and they must ensure that their work integrates easily with the other subsystems. This motivates you to have a core architecture team which identifies, supports, and evolves a common architecture across the various sub-teams.At the beginning of a large project you should identify your most experienced developers and abstract thinkers, as well as a few people that you want to see get some architectural experience, and invite them to be members of the core architecture team. You want to do this for two reasons. First, you want good people. Second, each of the development sub-teams will include at least one member of the core architecture team. This increases the chances that each sub-team understands and follows the overall architecture and that the core architecture team will not ignore portions of the system. Furthermore, it ensures that each sub-team has some senior people on it with an understanding of the architectural vision. Frankly, this is something you would do on any large project, agile or not. Agilists are very practical, we're more than happy to adopt good ideas from the traditional community.The core architecture team is responsible for identifying the initial architecture then bringing it to the rest of the project team for feedback and subsequent evolution. Architects will typically do this during iteration 0 of the project, which for larger projects can prove to be several weeks in length. Their goal is to identify the subsystems -- critical information required to identify not only the potential sub-teams but the skills required on those sub-teams. At this point in time you also want to identify and agree to the interfaces to these subsystems. The interfaces will change over time, so be prepared to refactor your code accordingly, but the goal is to enable the sub-teams to focus on their portion of the system without having to worry about what the other teams are doing. This strategy is something that Grady Booch calls "managing to the seams."[1]To avoid an ivory tower architecture, the members of the core architecture team take active roles on the development sub-teams, communicating the architecture to other members of the sub-teams and working with them to prove portions of the architecture via concrete experiments. From the point of view of the development sub-teams, the architect acts as both an architectural consultant and as an active member of the sub-team. In other words, the architect is another member of the team who gets his hands dirty coding.The core architecture team will find that members need to get together occasionally to evolve the architecture as the project progresses, negotiating changes and updating any architectural model(s) as appropriate. These working sessions will be frequent at the beginning of a project and will be needed less and less as the architecture solidifies. It will be common for members of the development sub-teams, who may not be members of the core architecture team, to be involved because they may have some specialized knowledge or experience to share with the team. The best meetings are short, no more than an hour in length, and are often held in a room with lots of whiteboard space. Everyone should come prepared to the working sessions, willing to present and discuss their issues as well as to work together as a team to quickly come to resolutions.You may even find that you need to scale to an even more difficult situation: some projects are part of a larger program which may comprise several dozen other projects which are implemented over a ten to fifteen year timeframe. Your core architecture team and the models which they create will help to promote a shared, evolving vision throughout the lifetime of such an effort.



Parting Thoughts

You'd be hard pressed to find an agile team that doesn't model on a regular basis, and this includes architectural modeling as well. This article overviewed a collection of architectural strategies for agile software development teams. I invite you to join the Agile Modeling mailing list, www.agilemodeling.com/feedback.htm, so that we can continue to discuss agile approaches to architecture, requirements, and design as a community. I also invite you to get involved with the Eclipse Process Framework (EPF) at www.eclipse.org/epf/ where we are developing both an open source editing tool and open source process materials describing agile development methods and techniques. There is a lot of interesting work going on around agile architecture techniques and I'd love to see you get involved. I'd like to thank Per Kroll and Jim Ruehlin for their feedback regarding this article.



Suggested Resources

The Agile Data Site, http://www.agiledata.org/, contains several articles describing agile approaches to enterprise architecture. The Agile Modeling Site, http://www.agilemodeling.com/, contains a large number of articles about agile modeling techniques, agile requirements, and agile architecture.The International Association of Software Architects (IASA) Site, http://www.iasahome.org/, is a great resource for IT architects. Grady Booch's Architecture blog, www.booch.com/architecture/blog.jsp, is a great resource for anyone interested in leading-edge ideas concerning architecture, Service Oriented Architecture (SOA)s, and software development in general.IBM developerWorks Architecture Forums and Community, http://www.agilejournal.com/www.ibm.com/developerworks/architecture/community/, offers a wide range of resources for web services, SOA, J2EE, UML, and architectural techniques.
[1] See Grady Booch's book Object Solutions: Managing the Object-Oriented Project, Addison Wesley, 1995.
About the AuthorScott W. Ambler is the Practice Leader Agile Development in IBM's Methods Group and is a fellow of the International Association of Software Architects (IASA). He is the founder of the Agile Modeling (AM), Agile Data (AD), Agile Unified Process (AUP), and Enterprise Unified Process (EUP) methodologies. Scott is the (co-)author of several books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, and The Enterprise Unified Process. Scott is a Senior Contributing Editor with Dr. Dobb's Journal and his personal home page is www-306.ibm.com/software/rational/bios/ambler.html
Written by Scott W. Ambler Thursday, 09 November 2006 06:43

Four Strategies for Task Allocation

Iteration and release planning are keys to successful agile projects, but overall have a relatively small impact on a developer's day-to-day life, compared to the daily planning that takes place each morning. The strategy a team uses to sign up for work has significant implications for what a developer's day will look like, impacts his work style and habits, and ultimately can significantly impact the overall success of the iteration. Unfortunately, the agile community gives relatively little guidance in this area. In this article, I will share my experiences with three strategies for task allocation, drawn from several typical agile projects with two to three week iterations.

Strategy 1 - Ad Hoc
The simplest approach to selecting tasks is ad hoc. Any developer can sign up for any task he feels like working on that day.This strategy has much to commend it. Since it maximizes flexibility, in theory this should provide the highest potential velocity. The team can sign up for work in whatever order makes the most sense. If a task is blocked for some reason, the ScrumMaster can take responsibility for removing the block, and the rest of the team simply picks up tasks that are not blocked. Higher risk items can be addressed earlier. Developers can choose tasks based on their energy that day, their interests, and any other relevant factors. It is also fairly easy to accommodate events such as unexpected absences by team members.This method also supports a variety of good practices, such as switching pair programming partners frequently (at least daily), least qualified implementer, and collective code ownership. Few silos of knowledge about functionality or architecture develop, and when they do, it's an easy problem to fix.Finally, this approach maximizes the idea of team accountability. The entire team is responsible for getting all the tasks done. We all succeed or fail together. This strategy also has some potential weaknesses, which generally manifest themselves on less mature teams. Chief among them is the problem that a team member can easily slack off, either by "pairing with" (read: "watching") stronger developers, or by consistently picking up trivial tasks and exaggerating the time needed to complete them. While this is usually easy to detect, it's quite hard to objectively demonstrate the poor performance or unambiguously define the desired behavior - which makes it tough to manage. While a better approach to pairing will help detect or prevent this, a team may be better off with a strategy that makes it harder for slackers to hide.A second weakness of this approach is the unfortunate tendency for many stories to be in active development at any given time. As developers move from one "juicy" task to another early in the iteration, it's very tempting to leave the less exciting tasks for later. Ultimately this causes many stories to get done at roughly the same time - about 15 minutes before the code freeze. This can overwhelm QA and the Product Owner, who do not have time to accept the stories or adequately test them. The resulting blame game during the demo and retrospective is anything but productive.The third weakness with this approach is a flip side of its strength, team accountability. No single individual is directly accountable for much of anything other than his daily tasks. When everyone is responsible, it can work out that no one is responsible. This can result in a lot of stories that aren't quite finished, but nobody feels particularly bad about it.

Strategy 2 - Dedicated Developer per Story
Another strategy for signing up for work is the dedicated developer/pair per story. A developer, or a pair of developers (depending on your practices), signs up for a story and is responsible for seeing the story to completion.If the ad-hoc approach is the most agile, this has got to be the least. It is the least flexible and destroys any real sense of team accountability. However, it is not without some strengths and other characteristics that might make it appropriate in certain situations.One major advantage of this approach is that it provides nowhere for "slackers" to hide. Each developer (or pair) is responsible for seeing at least one story through to completion. Whatever status he may report at the daily standup, at the end of the iteration, the story is either done or not. This provides the necessary objective evaluation that might be needed to deal with team members who are less than fully engaged on the project, should it come to that.A second advantage is that it causes each developer to gain a comprehensive understanding of the overall design of the system, since each developer will likely need to modify most or all layers of the application during the course of one or two iterations. Any given story may not include all architectural layers, but over time it's very likely a developer will gain experience in each piece.This approach may also work better with teams who can't, or don't want to, collaborate very much. Each developer can focus almost exclusively on developing his story without too much interaction with the rest of the team. This is not the most desirable scenario, but could be appropriate. In particular, a team that is not co-located on a regular basis, or is separated by several time zones, might be more effective with this approach. It may also suit teams who are new to agile and have been used to working independently.This approach, however, has significant drawbacks. By maximizing individual accountability, it effectively destroys team accountability. Together with the minimized necessity of collaboration, this approach eliminates most of the behaviors that make a team, a team. There is no real common goal or cooperation on a daily basis.The "dedicated developer" strategy will reduce or eliminate architectural silos (e.g., only one or two developers understanding the back-end system) but introduces strong tendencies for silos built around particular features (e.g., only one developer understands how the order notification code works).Because one developer is dedicated to one story, if the story is blocked, the developer is blocked. Similarly, if the developer is unavailable (due to illness, vacation, production emergencies, etc.), then the story will not likely get completed. It's unlikely that another developer will be able to come up to speed on the story in time to complete both it and his original one.Finally, this strategy shares a weakness with the "ad hoc" method, in that many of the stories will tend to be completed right at the end of the iteration. It's also possible that several stories will be "almost done" but not completed. If the team has overcommitted, several developers may find they have bitten off more than they can chew, and subsequently all fail to complete their individual stories. Ideally, the team should have realized this, abandoned a story or two, and gotten the rest completely done. It's better to have, for instance, 75% of the stories completely done, and 25% not even started, than have all of the stories 75% done and none finished. The "dedicated developer" strategy does not accommodate this situation, and worse, removes any real incentive for a developer to sacrifice "his" story to help the rest of the team.
Strategy 3 - Story Swarming
Using a "story swarming" strategy, the team "swarms" each story in turn, seeing each one through to completion before starting the next. In practice, it's frequently not possible for all the developers to work on the same story, so there are generally two or three stories being developed at the same time, each by a subset of the team. This practice has many advantages and avoids most of the problems faced by the two strategies previously discussed.Story swarming promotes team accountability very strongly. Although the entire team may not be directly involved in the development of each story, a large percentage of the team will be. This generally avoids the problem of a developer feeling that he is only accountable for delivering his own stories or tasks. Granted, the subset of the team not directly involved in a given story may not feel a strong sense of accountability, but enough of the team does that the concept is preserved. Additionally, by focusing on completing a story before moving on to a new one, this approach ensures that developers feel completely accountable for delivering the stories they do work on, rather than just completing the tasks they happened to sign up for. From this perspective, team accountability may be even stronger using this strategy than with the "ad hoc" approach.Since several developers will work on each story, most of the benefits of "ad hoc" approach are retained. There are enough developers involved with each story to support practices such as pair programming, as well as avoiding architectural silos or silos around particular features. It requires a high level of collaboration among team members. This strategy also accommodates unexpected absences and similar events well; the other developers working on that story can generally complete it.A key benefit of story swarming is that it avoids the problem of many stories being finished simultaneously at the end of the iteration. Instead, it provides a fairly continuous flow of stories that can be tested and accepted. There may be one or two stories that are finished at the very end of the iteration, but the rest have been completed earlier, giving QA and the Product Owner plenty of time to verify them. And since working software is the best indicator of progress we have, this approach can give a better picture of the iteration's progress than even a daily burn-down chart. This approach also resolves the danger of several stories being almost, but not quite, ready. If the team doesn't complete its work, it's generally only one or two stories that aren't done, so this approach allows a more acceptable failure mode. It's better to complete 75% of the stories, and have no progress on the remaining 25%, than to be 75% done with all the stories.It's also worth noting that there is little difference between this approach and the kanban approach to agile development . It is also compatible with iterationless approaches; story swarming accommodates very short iterations, and would accommodate variable length iterations easily, delivering one story per iteration. The strategy is not without its weaknesses, though. By focusing exclusively on a couple of stories at a time, a team might fail to address a risky item on another story in the iteration until it's too late. For this reason, a team might want to "cheat" a bit by having a developer identify and address risky items early in the iteration - for instance, prototyping a new feature and sending it to the Product Owner for feedback -rather than swarming a story with the others. After addressing those items, he can rejoin the rest of the team in working on their stories. This is a natural behavior under the "ad hoc" strategy that should not be forbidden by an overly-strict application of the story swarming rules. Story swarming is also vulnerable to a blocked story impeding the progress of several developers. Depending on the nature of the block, it's possible that the team could work around it for a while, and then leave one developer to continue trying to resolve it while the others worked on a new story.Finally, story swarming is slightly vulnerable to the problem of slackers spending all their time "pairing" or working on trivial tasks. However, since the set of available tasks is restricted to just the ones on the story being currently developed, it's much easier to detect and address this problem.
(The fore mentioned three strategies - Written by Robert Williams )

Strategy 4 - Team Leader/Tracker Recommendation
In the standup meeting, the technical lead (or team leader/tracker) who knows the capabilities of his/her team members can recommend (allocate optionally) to the team members the tasks of this day, and allow discussions with the team if there is any objection.
This strategy enables the team leader to resolve conflicts, develop the team technical skills, follow the plan of training & orientation more easily and provide more sustainable monitoring.
(Written by Ahmed Mahdy)

Recommendations
Story swarming is a good default choice for many teams, since it mitigates the weaknesses of other approaches without incurring any unique dangers that can't be worked around, and provides the unique benefit of a continual flow of stories. This approach is suitable for most teams in most contexts.Very mature teams may want to opt for the maximum flexibility and higher potential velocity offered by the ad hoc approach. These teams must ensure that team accountability maps directly to individual accountability, and establish a process to ensure that stories have enough time for testing and acceptance.Teams in very special circumstances may benefit from dedicating one developer per story, although this strategy has significant drawbacks. It may be useful for teams that can't collaborate as much due to geographic factors, and for teams that are very new to agile. Aside from those situations, the drawbacks associated with this strategy make it less appropriate than story swarming or ad hoc task selection.
(Written by Robert Williams )

What is Best, Scrum or Kanban?

I have for some time been thinking, what is best, Kanban or Scrum. I can't make up my mind so I decided to write an article in two parts, one where I wear the "I love Kanban" hat and one where I'm wearing an "I love Scrum" T-shirt.First I would like to tell you shortly what Scrum and Kanban is.Scrum in 1 minuteScrum is about getting back to the time when the company was small and everything was easy and ran smoothly. Back then projects were small, teams were small, releases were small and communication was easy. Best of all, we were efficient.In Scrum we split our big project into small projects as we work on timeboxed iterations called sprints. We split our big team into small teams (still with all the skills we need) and launch often. If we are more than 20 employees we probably have a problem knowing what the other departments and customers are needing so let's bring someone into the team that can represent them. To help communications from the team to the rest of the company we have our plan and current status visible. The plan is called the sprint backlog and the status is shown on the scrum board. Here is an example: The person we brought in to represent all stakeholders is called product owner and is responsible for prioritizing a list with features that will be developed for the product in the future. This list is called the product backlog.To make Scrum a process we add some small but necessary meetings: a planning meeting, daily synchronizing meeting and meetings to improve product and process. We decide the length of our iterations and aim to deliver something valuable after each iteration.

Kanban in 1 minuteScrum is simple but Kanban is even simpler. Just visualizing your workflow and limiting demand to capacity is enough to call it Kanban. Let's start by looking at the roots of Kanban. It's a way, invented and used by Toyota, to get a good flow of parts to their plants. Kanban is just a card attached to the part and when the part is used the Kanban is sent as a request to the supplier for more parts. The physical card is actually sent to the supplier who is attaching it to the next pert sent. Since the cards are re-used and no new cards are entered in the circulation Toyota limits the number of parts in stock and at the same time make sure new parts are ordered as soon as they are needed.

In software development Kanban is a limited promise of work. A Kanban board is a number of placeholders for work to be done. A typical Kanban board can look like this.

Each team has decided their limit and drawn as many squares as the limit allows them to. Whenever a task is done it will be moved to the next group if and only if they have free Kanban squares. Else the task is stuck. If there is nothing more to do we have a problem with the flow and we need to work together to solve what is stopping us. While Scrum is focusing on delivering on commitment Kanban is focusing on getting a smooth flow. In common for Scrum and KanbanThere are a lot of similarities between Scum and Kanban. Some examples are:
A strict prioritization (it's obvious what to do next)
Self-organizing teams (see below)
Transparency (show what you've done, your current status and what's next to do)
Inspect & adapt (improve your product and process based on facts)
Pull scheduling (see below)
Good communication and collaboration Self-organizing teams is when the team themselves are supposed to figure out how to solve problems, remove impediments and optimize their process. They should base their decisions on facts to inspect and adapt accordingly.Pull scheduling means the team is pulling work instead of having it pushed. This will limit work to capacity and lower stress, which is bad for both health and quality.This is why I prefer ScrumSo, now that you know what Kanban and Scrum is, it's time to decide which is best.
I start by putting the Scrum T-shirt on. Look further down if you like to read the part where I love Kanban.I concentrate on some areas where Scrum and Kanban differ:
Iterations - In Scrum you work in iterations. Kanban sees development as a forever ongoing flow of things to do.
Commitment - In Scrum a team commits to what they will do during a sprint.
Estimations - In Scrum you need to estimate to be able to have a velocity. In Kanban it's optional since focus is on time-to-market.
Cross-functional teams - That's one of the pillars of Scrum. For Kanban it's optional. Efficiency driven by commitmentBy asking a team for a commitment they will get a positive stress knowing that people from outside will see if they can do what they committed to. It also gives an energy boost at the end of the sprint when the team has the goal within reachable distance. After the sprint, the team can feel relaxed and gather some new energy for the next sprint. It's psychologically nice to not feel you are in the middle of a never-ending stream of things to do. Instead Scrum concentrates on one sprint at a time and allows you to focus only on those things you have decided to take on in the sprint. By working in fixed length iteration you get a nice rhythm the whole company can feel and adapt to.The value of estimatingEstimating is not a waste of time since valuable information is transferred from the product owner while the team asks what they need to know to be able to estimate. The same thing applies to commitment. To be able to commit team members need to know what they are committing to. They simply have more interest in getting information from the product owner so they listen more carefully. And they are just asking for the information they need which makes the meeting very efficient.Even though you can predict when a project is done, just by counting stories left, it is more precise if each story is estimated as well. Prediction is important when more departments, like marketing, are dependent on your work. It gives a more serious feeling.Slack at end of sprintsIf there are some time at the end of a sprint that's valuable even if the time is not big enough to start developing new features. This is time developers can use to improve code quality or the development environment. Both will give better efficiency in the long run.Build teams with cross-functionalityWorking together in a cross-functional team is a psychological thing. You are able to go the whole way from concept to released product together as a team without dependencies. You are not just a cog in the machinery. It's also fun and helps you grow as a person. By helping each other, knowledge is spread which lessens dependencies on each person. It also helps prioritize since features can be built without considering which knowledge is available. To coordinate between people with the same skills who are sitting in different teams you can have virtual team meetings as often as needed.Scrum is best for beginnersI know, you can do all those things even when doing Kanban but they are optional and since they are optional you might just not do them just because you are too lazy to challenge the usual procedures or structures of your company. If you are new to Agile development it's better to have a method guiding you to do the right things. Just read the book and implement it. Later when you get used to it you can start experimenting and eventually get better performance. If you start experimenting too early you might end up with waterfall or chaos but still calling it Agile. Kanban is more advanced because you need to make a lot of decisions without having many facts.This is why I prefer KanbanNow it's time to take off the Scrum-T-shirt and put on my "I love Kanban"-hat.
Kanban is based on Lean principlesKanban is Lean and has been around for 50 years and has shown to be successful. Things are seen as a flow without iterations. Not many rules. It's just a focus on reducing work in progress, strict prioritization and limiting demand after capacity. Besides that you have the normal Lean principles of:
Quality
Just-in-time (decisions and facts just when they are needed)
Short lead-time (quickly from concept to cash),
Kaizen (continuous improvement)
Minimizing waste (everything that is not adding value to the customer) No meetings if it's not adding value to the customer. Most of those things are fine with Scrum but I can sometimes think Scrum has some waste. Here I will mention some areas where Scrum practices might be waste.Estimations might be wasteIf a product owner knows what needs to be done and the only goal is to have it done as soon as possible, why spend time on estimating? In Scrum, estimations are needed for a team to know how much to commit, to calculate velocity and for the product owner to decide on prioritization. If none of this is needed, it's waste and we shouldn't do it. If you like to measure velocity you can instead count the number of stories done per week or month. While talking about measurement why not look at something the customers are interested in, lead-time. That is, the time it takes for the customer to get what he or she ordered.Constant flow If the team is done with a story and there is not enough time left in the sprint to complete the next, it's likely no one works hard the remaining time and that's waste. Kanban is trying to get a steady and non-stressed but high flow of work running through development.Sitting with people that can help youIn Scrum a team is cross-functional and sits together with the people working with the same project and not with the ones with the same knowledge. Let's say you work with sound effects for a computer game. Then it's not much help to have a java-programmer beside you. It would be more valuable to sit with people doing the same things as you do who can help you with tools and practices.

No possibility to commitIn Scrum, the team commits which does not work very well for a team with support issues. They get a lot of disturbance and commitment is not worth anything since the ones disturbing them don't care about commitment. A commitment you can't control gives either frustration and stress or demotivation.Kanban for support and operation teamsSupport and operation teams are often interrupted. It's part of their job. Frustration comes when interruptions are happening just because there were no time for pre-emptive work. Just by having the pre-emptive work on the board gives focus to fix the hardest problems one-by-one, which gives less interruptions and more time to work pre-emptively. It becomes a good circle. A Kanban board for an operation team can look like this:

Most important are the urgent problems that arise. Secondly, daily duties must be done. Then the team members can take care of other projects, usually to improve stability in the operation environment. The limitation on the number of parallel tasks gives focus to be done working on improvements, not just starting them.Many options gives freedomKanban is simple with few constraints, which gives you freedom to change your process step by step. Either you go from waterfall or chaos, your first step is to visualize and limit your flow with a Kanban board. When you have your flow visualized you add whatever work is needed to thrill your customers. Your improvements might be decided during a monthly retrospective meeting or on a daily meeting. ConclusionI still can't make up my mind if I like Kanban or Scrum the most. My conclusion is, not very surprisingly, that it depends on the situation. See them as two different tools and find out which tool is the best for your situation. Maybe you start with Kanban and end up with Scrum or maybe you don't. Maybe you'll start with Scrum but change to something more like Kanban. Whatever you do, just make sure you do what is best for your customers.

Ref:

http://www.agilejournal.com/articles/17-articles/1737-what-is-best-scrum-or-kanban

Group Coherence for Project Teams - Practice for Continuous Improvement

One of the principles in the Agile Manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This principle guides both aspiring and seasoned Agile teams in the pursuit of continuous improvement and can support whatever Agile adoption path an organization may choose. Kent Beck adds observations about this topic.
"'Continuous' improvement is a bit of a misnomer. It means continuous awareness, responsiveness to feedback, and openness to improvement. When you know how to improve, then you improve. You make a change; observe the effects; then digest the change, turning it into a solid habit. Eventually you hit a plateau from which you can absorb more feedback and identify the next opportunity." (Beck & Andres 2005, p141)Extreme Programming Explained: Embrace ChangeAddison-Wesley Boston MAThis quote describes a process that we recognize as Practice, defined in our previous article, Group Coherence for Project Teams - Common Purpose, as "The ability to identify difference and learn through attentive repetition, either for individuals or groups... Through Practice we can get a feel for the contextual application of knowledge, rather than the acquisition of individual techniques." Practice, an ingredient of Group Coherence, is the only ingredient that the research group found to be connected to every other ingredient. Beck refers to continuous improvement in the context of an individual's learning process. "Change myself, then offer the fruits of that change to others." (p141) Practice is a process through which groups can also learn and change.
Although individuals contribute to the features developed by a project team, the product of their work (the features themselves) does not belong to an individual, but is the product of the entire group. Just as the music produced by a jazz ensemble includes the individual improvisations of each member, the music belongs to the group. To whom does the technical debt and code quality in software systems belong? Why do some environments not take advantage of the opportunity for iteration provided by Agile methods to turn releases into non-events?We propose that items such as code quality, technical debt and release cycles have tacit ownership at the group level. This is unconscious, as group ownership is often minimally recognized in organizations. These unacknowledged group items are vulnerable to decisions and prioritization made by individuals without the group's voice, at the expense of the opportunity for the group to learn. Untapped group learning can be brought to awareness through group Practice thus supporting the pursuit of continuous improvement in these often challenging areas.Challenges - Release ProcessLarge organizations are prone to centralize their release process in an attempt to protect their live systems from rogue updates, or their customers from a greater pace of change than they can absorb. A common implementation of this protection is to use an additional team for production releases independent of the development team. In reality the development team is invariably called in to resolve issues that surface during the release process. This illustrates tacit ownership of the release process that belongs to both release and project teams. The whole-group ownership of the release is not acknowledged. The resulting integration feedback loop is late, long and cumbersome and releases are big events involving multiple departments and stressful interactions with long hours.In environments where a centralized release process is assumed to be the constraint and not up for discussion, Agile is stunted in its ability to provide continuous Practice in the software delivery. A common reason to avoid the process conversation is the excuse that "our complex business needs such a process." However, by not allowing Agile teams to release to production early and often, we prevent the Practice that would allow them to turn the release process into a non-event. Challenges - Technical DebtThe centralized release process implementation can result in development and test environments with limited ability to test performance, integration, code coverage or product usability. This forces a lot of critical testing to be done during the release rather than the development process. The project team's best efforts to deliver a "safe" and tested feature set become little more than guesses. The developers have to attempt all their testing in the System Test environment. This is like developing blind as this environment lacks the connections to the system's external integrations.The project team's group product consists of all the features and all the tests. Centralizing the release process fragments group ownership. Developers focus on unit and system tests and don't have access to accomplish the full set of critical tests. The release team can focus on the tests the developers can't execute but release engineers do not have access to the code. The result surfaces technical debt that neither team is empowered to own. When responsibilities for the group product are fragmented, no whole group exists to own that product. Practice by the whole ownership group could improve both the release process and catch technical debt earlier.Challenges - Code QualityCustomers and product owners may press the project team for a wide feature set and an aggressive delivery date. This can compromise code quality, causing the developers to express concern. The two groups might have a different interpretation of the Agile principle for "minimizing the work not done". Customers might think that refactoring is unnecessary waste since this effort results in no visible changes to the application. They often challenge the value of what they might describe as "writing the code twice". However, once a feature is implemented, an Agile development team refactors the code to make it more efficient to run, cheaper to maintain and easier to extend. So who does the code quality belong to? The customers are paying for the work but the developers have a fiduciary duty to ensure that the customer receives maximized value. The code quality is part of the whole-group product. This disagreement shows that in this case the true communication never happened. The need is to resolve the disagreement and create collaboration.Code quality is built into the software over time. If the opportunity for collaboration is limited to the final stages of release preparation, the ability to identify deficiencies in code quality is also limited. An occasional look at the system does not provide the opportunity to develop trust, align goals and expectations, and learn to communicate effectively as a team. Practice to Enable Whole-Group OwnershipWe would like to share our personal experience of one way in which we have turned the tacit group ownership of release process, technical debt and code quality into a conscious seamless part of the day-to-day interactions of a whole project team. In a financial risk management system like the one in this example, projects waited until a complete financial model was implemented in C. Once the traders validated this model, the developers could begin to extend their risk management system to use it. After this software development was complete, operations and support processes could be created. These sequential handoffs were an established project life cycle.When market conditions suddenly invalidated an existing financial model, a business need arose to extend the risk management system considerably without knowing what replacement model to use. Using an invalid model put traders at great financial risk and under considerable stress to manually adjust every quoted price. This was a crisis that could not wait for a sequence of handoffs over the next 12-18 months.Instead, by initiating communication with all the stakeholder groups simultaneously, it became clear that each had a part of the process and also a part of the solution. To make the communication among the stakeholders both practical and concrete, developers created sandbox versions of production for each conversation among traders, financial modelers, trading administrators and support engineers. The increased level and quality of communication led to the realization that the whole group owned the system.Implementing the sandboxes removed the handoffs and enabled the participation of the whole team throughout the project. The whole group was able to take ownership of the technical debt, code quality and release process, since each of these sandboxes made these items visible to everyone involved. Most sandboxes were set to refresh their database daily from the live system, and would be extended with all the daily code changes from the development system as well. In addition, the financial modelers were evolving multiple analytic libraries, and the latest versions of their work were also applied to the sandboxes on a daily basis.Traders and their administrative staff picked up any drop in code quality on the part of either the developers or the financial modelers immediately. Any technical debt that impacted the usability of the system or the daily generation of risk or profit and loss figures was also picked up immediately. Degradation in the computational performance of the application was obvious to everyone straight away. And of course, the release process was being tested on each sandbox every day. An Environment for Group LearningThe previous example illustrates how software development can be a group learning process. This solution allowed for both Practice by the entire group and also for continuous improvement in several areas. For example, the financial modelers were able to share each other's work and thus were able to explore four or five times the normal number of candidate models to develop a solution, with each cycle of modeling providing input for continuous improvement. The traders were able to test numerous hypotheses about the market parameters that would influence the new models, thereby contributing improvement to their business model and trading strategy.Given the crisis, the stakeholders were willing to do away with the traditional handoffs, include all the participants and create a shared sense of common purpose. This holistic project interaction initiated group Practice in which self-organization and group learning spontaneously emerged. When somebody suggested something that the group could do, the group provided a way for them to try it, improving the group's environment with each cycle. Eventually, the group was able to create its ideal environment for continuous improvement. This environment was the result of acknowledging the previously tacit group ownership of the risk management system. The Practice allowed a new self-organization to emerge. ConclusionWhen everyone is able to see and experience the progress made throughout the development process, they will offer and receive feedback without being solicited or prepared. This open group exchange is one result of Practice. To guide a collection of Agile practitioners and their project stakeholders towards Group Coherence, it is important to provide opportunities for the group to Practice ‘being a group'.Without ‘being a group' the team has no access to the tacit knowledge. Once it accesses its shared understanding, the team develops a knack for group learning. Group learning is necessary for a team to embrace suggested improvements. Continuous improvement depends on group learning provided through Practice.Guiding a group from Practice to continuous improvement can allow practical results in such challenging areas as code quality and technical debt and can make releases so frequent, tested and drama-free that they become invisible.


Ref: http://www.agilejournal.com/articles/17-articles/1742-group-coherence-for-project-teams-practice-for-continuous-improvement