CMMI - Organizational Process Focus (OPF) in Agile environment

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.

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

Agile Automation: Automating The Agile Release Process

Agile methods promote a process that encourages frequent inspection and adaptation, the rapid delivery of high-quality software, and responding to changing circumstances rather than strictly following a plan. Therefore, automation is key for the success of the Agile release process.
To make sure Agile projects run smoothly and rapidly, companies must automate all repetitive activities – such as installing new builds of complex, multi-tier, multi-server software. Automating application updates in development and QA environments accelerates the release process, increases flexibility and efficiency, and enables companies to keep the Agile promise of efficient, rapid delivery of high-quality software.
In an Agile environment, software requirements are constantly changing. The Agile promise of ensuring customer satisfaction by rapid, continuous delivery of useful software means that software is delivered in less time, but each released build must still be fully tested. It’s obvious that in this type of environment, manual processes will fail. Manual processes can only work if your product is easy to deploy, such as a desktop application deployed on a single computer.
Automation of the Agile release process by Nolio enables companies to automate the deployment of testing labs and the updating of development environments several times a day. This allows developers and testers to always work with the latest build, even in complex application environments, which are constantly changing.
In the rapidly changing environment of the Agile release process, your business simply cannot afford slowing down or compromising product quality because of human errors, failures and downtime. Fully automating the Agile release process is the answer.
—Nolio Application Service Automation is a software platform for designing and executing automated application service workflows across the data center, enabling reliable, effective processes for the management of application change.

Process improvement meets 'Peopleware'

People are the key asset of any organization

by MARY SAKRY

If you have heard Timothy Lister speak, you can better understand my enthusiasm for his work. This issue I would like to talk about how important "Peopleware" concepts can be to your process improvement efforts.

This article will quote heavily from authors Lister and Tom DeMarco. All quotations are straight from "Peopleware."

Determinants of process improvement success

When we think of process improvement, we must consider the balance of three components: process, people, and tools. All three of these components play an important role in determining how successful the process improvement results are.

We need good processes to accomplish our software development and maintenance with the appropriate tools to support these processes while realizing that it is people that do the work and use those processes, methods and tools. Therefore, ultimately people are responsible for the success or failure of the improvement effort.

Lister knows how to drive home the importance of the people who create software better than anyone else. He always maintains a level of wit that makes his important message palatable yet ensures that his message hits the mark.

As you work on your process improvement issues it is important to keep this element in mind. Most SEI Level 12 findings are behavioral in nature, and organizations can do well by paying close attention to his message.

"Peopleware" in a nutshell

Here I state several points made in "Peopleware." My intent is to tell you just enough so that you will read the book yourself. So I won't give much detail.

The major problems of our work are not so much technological as sociological in nature.

"We're all under a lot of pressure to improve productivity. The problem is no longer susceptible to easy solutions, because all the easy solutions were thought of and applied long ago. Yet some organizations are doing a lot better than others." Several helpful ideas to improve productivity are offered.

The authors examine the office environment and what can be done to enable higher productivity.

"The manager's function is not to make people work but to make it possible for people to work."

The book tells us how to: "get the right people, make them happy so they don't want to leave, and then turn them loose."

What's in the foreground of most of our prized work memories is team interaction. When a group of people fuse into a meaningful whole, the entire character of the work changes."

"In the best work groups, the ones in which people have the most fun and perform at their upper limits, team interactions are everything. They are the reason that people stick it out, put their all into work [and] overcome enormous obstacles." Lister and DeMarco present some good ideas on how to grow and maintain productive teams.

Finally they leave us with the notion that work should be fun. "We need people to recognize the occasions when they are being asked to do something silly -- and actually say so. Once it's been said out loud, (the organization) can't ignore it any longer."

What does all this mean in relation to process improvement? And why should you care?

First of all, some of you may have had a process assessment, and if you have, you may have been surprised that so many people-oriented issues surfaced. If you have not used an assessment as the basis of your process improvement, then you should be advised that you may have missed some critical issues that are people-related.

No matter how you have set up your improvement program, you must deal with these issues as they are foundations for the improvement work to follow. For example: If people are expected to complete projects based on unrealistic schedules estimates or work in an environment that allows continual interruptions, then to think that they will be able to make meaningful process improvements may be unreasonable.

As a rule, people enjoy working on process improvement as long as it is not seen as an additional burden to an already hectic schedule. When people are dedicated to process improvement, it should be considered part of their job and time must be allocated for the effort.

Keep the software people happy

Be sure to keep a balanced emphasis on people, process, and technology.

If, during your efforts, you are unable to help people solve their real problems or are unable to convince them that you can help them solve their real problems, your effort will fail. Remember, the software professionals are your customers and you want to keep them happy.

Product Backlog Rules of Thumb

While working with Product Owners over the years I have learned some rules of thumb that help make their Product Backlogs more manageable. Some of these rules of thumb I learned from other people and some were learned through trial and error.
Remember that the statements contained in this article are just rules of thumb intended to help guide your management of a Product Backlog. They are not rules to adhere to no matter what. Always use common sense when applying a rule of thumb to your particular context.The first rule of thumb that I would like to discuss is the:
Keep your Product Backlog between 50 and 100 items total
It is common for a team or organization to implement Scrum and find their Product Owner overwhelmed by the mass of the Product Backlog. The Product Backlog is filled with every feature request, suggestion, defect and infrastructure improvement. The Product Owner is no longer able to effectively manage the Product Backlog and maximize the value of delivery through prioritization.To combat this unmanageable mess, gather related Product Backlog items into a single, larger Product Backlog item so they can be managed as a group. As these combined Product Backlog items get higher in priority they can be easily expanded into their smaller, contained items and prioritized individually among a smaller subset of high priority items. Also, go through the Product Backlog and remove items that are not directly aligned to the product roadmap. Frequently, items are kept in a Product Backlog because they sound like a good idea but are not aligned with the overall product strategy. Figure out if these items should be represented on the product roadmap or are they a distraction from the product goals.Next, lets make sure the Product Backlog is ready to conduct effective Sprint planning with by making sure...
The top 20 to 40 items are small enough to fit into the development team's Sprint
The top of your Product Backlog represents the highest priority items to be implemented by the development team. It is important to work with the team on making these items small enough to fit into an upcoming Sprint. Identifying the appropriate size of the top 20 to 40 items involves getting estimates of cost from the team. From these estimates, the Product Owner can gauge the appropriate size of items to fit into a Sprint. If the Product Owner believes a Product Backlog item is important but sized too large to fit into a Sprint then the team can help the Product Owner split it up into smaller chunks or simplify the implementation.An appropriate size could be described by the following formula...
The upcoming Sprint should fit at least 4 of the highest priority Product Backlog items
After a team has executed 1 or more Sprints they can calculate their velocity based on data from those Sprints. Velocity is the amount of Product Backlog delivered within a single Sprint. Calculating the velocity is a function of Sprint duration, team makeup, sizing nomenclature, and product technology. Therefore if any part of that function changes then the velocity is no longer valid. The best way to get predictability in team delivery is...
Keep the development team together working on the product with a continuous Sprint cadence
The rhythm created with each Sprint having the same duration will help the development team understand how much they can commit to in planning and deliver successfully as potentially shippable code by the review meeting.
Have a description of the Product Backlog item is usually not enough to make it clear for estimating by the development team. It is helpful to...
Put acceptance criteria on top 20-40 items
Acceptance criteria could be a bulleted list of capabilities the software should exhibit once the Product Backlog item has been implemented. These can be thought of as the functional acceptance tests for the Product Backlog item. The development could also identify technical aspects of the functionality as acceptance criteria with acknowledgment of the Product Owner.
If your list of acceptance criteria is getting larger than 7 then...
Break up the Product Backlog item into multiple items partitioned by common functionality within the original item.
Of course, there are also times where the Product Backlog item is too small and does not do enough on its own to create value for the product. In that case there is the following rule of thumb...
Each Product Backlog item should have at least 3 acceptance criteria
Having Product Backlog items that are too small is not always a bad thing but it could be difficult to manage and provide visibility into. I have found it also leads to Product Backlog items that are technical in nature without direct business benefit. The Product Owner could find it difficult to gauge the correct priority for an item that is too technical so...
Every Product Backlog item should present value that a Product Owner can understand and prioritize effectively
Abuse Stories can be used to drive out the value to users for technical infrastructure or architecture Product Backlog items. An Abuse Story identifies the cost of not addressing a technical aspect of the product. For instance, in the case of fraud, an Abuse Story such as the following could be identified as a Product Backlog item:
As a Malicious Hacker I want to gain access to credit card information so that I can make fraudulent charges
The acceptance criteria for this Product Backlog item would be the technical modifications that will be made to stop the Malicious Hacker from gaining access to credit card information. The risk identified in this Product Backlog item helps the Product Owner better prioritize beside other potential candidates for upcoming Sprints.
The entire Product Backlog should be prioritized in stack rank order
And...
The development team that is going to implement the product should estimate all Product Backlog items
These are the basics for Product Backlog management but I thought I should reiterate them. I often find that the Product Owner does not take time to prioritize their entire Product Backlog. If kept to a manageable size, the Product Backlog provides visibility to stakeholders, management, and the development team about what is coming in the near future. It is difficult to prioritize if the Product Owner does not have a cost to weigh against the benefit for each Product Backlog item. The team who is actually going to implement items off the Product Backlog should be the only people who estimate the items. No individual outside the group should tell the team what the estimates are. After the Product Backlog is fully estimated, the Product Owner should...
Generate a release burndown chart to monitor progress toward a release of the product.
Once you know how much the team can deliver each Sprint (velocity), you can do some ad-hoc release planning by going through your estimated Product Backlog and finding out how far they will be after n number of Sprints. This ad-hoc plan can be monitored on a release burndown chart to see if any changes must be made based on the reality of current implementation or emergent requirements.This listing of Product Backlog rules of thumb is just a start. I have found it helpful to go through this list with new Product Owners or Product Owners finding it difficult to manage their Product Backlog. As a Product Owner becomes more proficient in their Product Backlog management technique then they can step away from some of these rules of thumb to optimize for their environment.