80 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?summer10

The book starts with a presentation of Agile and Lean principles. The second part explains how Lean adoption can improve the usage of Scrum with an interesting table comparing Scrum and Lean accompanied by a list of practices to avoid. It devotes specific chapters to topics like release planning, visual control, quality assurance, product coordination and architecture. A final part is dedicated to more insight in the Lean approach. The book is pleasant to read. Each chapter has an abstract and the beginning and a summary at the end with some questions and further reading recommendations.

Besides the sometimes-annoying references to the authors consulting firm, this book provides interesting material on specific aspects of Agile software development projects at an enterprise level. Its main difference with other books on the same topic is for me the treatment of the management aspects of software development as the authors make their point for a stronger management role and intervention in Agile projects. This book will therefore bring more benefits to project and development managers that work for large organizations where the control aspect is important and the words “self-organizing teams” could be a serious “career limitation” move.

Reference

“Lean-Agile Software Development”, Alan Shalloway, Guy Beaver and James R. Trott, Addison-Wesley, 262 pages, IBSN 978-0-321-53289-3

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

Quotes

“What we need is a new attitude about process and how to manage process. Processes must be designed to assist the team in achieving management’s goal. Processes help the team get its job done: they represent accountability among team members about how they will work. [...] Is this possible? Yes! Lean provides the principles we need to do this. And we will not follow these principles blindly.”

“We often think of software as the end goal. But it is not. Software is a means to an end – a way of getting value to the customer.”

“Agile project management done in isolation violates the Lean principle of optimizing the whole. [...] There are other alternatives to Scrum, including Crystal, Feature-Driven Development and Kanban software development. They are good and they address specific challenges for teams. However, they, like Scrum, do not entirely address the bigger picture. By themselves, they do not address the entire value stream, which is what is needed.”

“While Scrum works well at the team level, using it as the primary method to guide Agility at the enterprise level has severe challenges.”

“Ken Schwaber and Mike Beedle define the Daily Meeting as composed only of team members, explicitly removing management from it – and subtly implying management is not accountable for deliverables.”

“Scrum works by exposing inadequacies or dysfunctions within an organization’s product and development practices. [...] The Scrum community generally concedes that about three in four of organizations implementing Scrum will not succeed in getting the benefits from it that they hoped for. The explanation is that many organizations change Scrum in order to accommodate the inadequacies or dysfunctions of the organization rather than solving their organizational problems. The implication is that Scrum gives them the tools to see but not to change.”

The beginning of the book describes the development process, providing a two pages description of COCOMO in the middle of it, and proposes way to improve it. The solutions focus mainly on an initial emphasis on architecture and modeling (naturally it is UML with some tools) associated with the recommendation for code reuse or component integration. I was hoping to find more useful material in the part dealing with “practical measurement for software engineering”. However the material is arranged around RUP phases and I found only one metric formula in the 50 pages devoted to this topic. There is some interesting content in this part, but it is only very high level.

This short book is close to be only a white paper for the IBM Rational Unified Process approach. It contains some interesting material for a software development manager wanting to think about introducing metrics, but its biased IBM approach and lack of directly useful content make it awkward for the experienced development professionals.

Reference

“The Economics of Iterative Software Development”, Walker Royce, Kurt Bittner and Mike Perrow, Addison-Wesley, 171 pages, IBSN 978-0-321-50935-2

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

Quotes

The most significant way to improve economic results is usually to achieve a software solution with the minimum amount of human-generated material. Our experience shows that managing scope and raising the level of abstraction through component-based technology and service-oriented architectures are the highest leverage techniques that make a difference

External stakeholders, including customers and users, cannot expect initial deliveries to perform up to specifications, to be complete, to be fully reliable, or to have end-target levels of quality or performance.

Web site: Rosetta Code

Blog Post: Are tools necessary for acceptance testing, or are they just evil?

Blog Post: New Agile Guidance and CMMI Guidance

Blog Post: 7 truths about Agile and Scrum that people don’t want to hear

Article: Designing Efficient SQL: A Visual Approach

Article: Are you using a toolset in your code review?

Tool: S.P.L.O.T. – Software Product Line Online Tools

Tool: RichNesse – Fitnesse WYSIWIG Editor

Tool: Review Board – Web-based code review tool

Video: Learn About Continuous Integration With Hudson

Video: A Guided Tour of a Whiteboard Culture

Video: Microsoft Visual C# IDE Tips and Tricks

Find more interesting links on the software development links directory, the software development tools directory, the software development articles directory, the software development blogs aggregator or the software development videos directory.

Software consultants are people hired on a temporary base mostly for what they are able to achieve. They will develop part of a software system or manage a project (I don’t want to talk here about consultants that are just hired to produce PowerPoint presentations). They will also provide some knowledge transfer to internal employees that are new to a specific technology. On the other side, the goal of agile coaching is more often to improve behavioral skills. Sport teams provide the first example of a coaching role that could come to your mind. There are however some differences. The agile coach aims at producing a self-organizing team and he acts only when issues occur to suggest solutions. The sport coach has authority over teams. He directs players’ roles and activities, although you should not minimize the roles of players as leaders especially in professional teams. The situation of coach of individual champions is also different, as the athlete usually chooses them… and fires them also.

The current agile adoption trend favors coaching and the economic crisis could be a catalyst to change work practices. However, I have few illusions that most of the corporations’ managers are truly embracing agile values. Getting up in higher management is still predominantly a power struggle, with more political consideration than the goal to empower employees. Many managers’ main objective is to justify their job (did you ever wonder why there are so many meetings?) and creating a self-organizing team is not intuitively something that helps to achieve this goal. Upper managers mostly don’t care about the type of software development process. They want working software applications delivered quickly and for a minimum cost. They will pay for Agile practices as long as they think that it could provide what they want and “cure” the problems that they attribute to their current software development model. They did the same thing before with Structured Analysis, Information Engineering, RAD, Object Orientation, CMM, ISO 9000 or UML – RUP (you can add your own silver bullet approach in this list). The name of “coach” or “consultant” can be used for external help, but ultimately companies will pay for people that deliver short term results and improving developers working condition is not always included in the list of valuable results. This is sad for Agile and developers as it could be one of the few approaches that value “Individuals and interactions over processes and tools“.

Participants: 392

Ending date: January 2009

Many software development concept of the 80s and 90s have left the spotlights of the professional press and the blogging world, either because they are soooooo obvious, as in “of course everybody is doing object oriented programming today…”, or because they didn’t meet the expected success, as the object oriented database that were supposed to replace this old relational SQL technology of the 70s….

CMMI is the successor of the Capability Maturity Model (CMM) or Software CMM. The CMM was developed from November 1986 until 1997 as part of the software process maturity framework project. Then the CMMI, where “I” stands for Integration, replaced the CMM. This is certainly not currently a hyped concept. You will find no CMMI category on dzone.com or infoq.com and the CMMI channel on reddit.com has two subscribers. I was therefore surprised to see that the adoption, ignorance or rejection rates for the CMMI were very close to the results achieved by a similar survey on Agile approaches ended at the beginning of 2008.

I didn’t find any former statistics about the CMMI adoption, so it is difficult to compare the results of this survey with other numbers. These survey results are telling us that formal process adoption is growing in software development organization. The importance of CMMI numbers can be explained by the geographical diversity of Methods & Tools readership: an important percentage is coming from Asia where the CMMI label is important to sell outsourcing services.

Knowing that CMMI adoption rate is close to the Agile rates, I wonder also if there were some overlap, thinking that there are many companies without a formal process. I found a survey on Dr Dobb’s with some numbers on companies doing both CMMI and Agile. According to this survey, the rates of success of Agile and CMMI projects are very close, just above 50%. You could interpret the results as whatever the process, as long as you have one, you improve your success rate, which would mean that some discipline bring rewards. These numbers also tell that you have still close to 50% chances of failure, which could mean that discipline is not easy to achieve in the software development world. Please note that the Version One Agile survey seems to indicate a higher rate of success for projects, even if the type of questions makes direct comparison difficult.

Although there are some evidences that CMMI and Agile can coexist, the overall impression of people dealing with process improvement is that there are still important cultural differences between the two communities. Even if the non-prescriptive nature of the CMMI is recognized by agile developers, the overall impression is that this approach are still leaning heavily on plan-oriented and documentation processes, thus conflicting with the lightweight aspects of Agile. To contradict this culture incompatibility, there is the example Systematic, where a CMM level 5 company has added Scrum on top of their process, gaining a 50% cost reduction. This maybe not so astonishing if you realize that CMMI and Agile both try to achieve process improvement and both require discipline. Managing one week Scrum iteration with daily meetings should provide a strict control of project progress. Therefore organizations that followed the CMMI way for a good reason, that is not just for having a label to sell their services, should be naturally attracted by the process improvement tools contained in Agile. Other organizations than Systematic have also added agile practices above CMMI, but the opposite doesn’t seem obvious.

Maybe the software development world would be better if people could see approaches like the CMMI or Agile as toolboxes and not cult-like concepts that should be embraced with a blind faith… and a tendency to see other movements as “heresies” that can only be condemned. As Chris O’Brien (Software Capabilities Manager at Gen-i) says “So CMMI and Agile are complementary, but the use of either should to be based on business needs. I believe both have an immense amount to offer and co-existence will make sense for many organizations – particularly those that are capable of applying learnings from their industry with intelligence and care, to achieve results.”

References

CMMI Main page at SEI

Software and systems firms embrace CMMI – India Trends – Express Computer India

CMMI or Agile: Why Not Embrace Both!

Dr Dobb’s article: Agile CMMI?

Mature Agile with a twist of CMMI

Scrum and CMMI Level 5: The Magic Potion for Code Warriors

Systematic Gains Chart

Methods & Tools Agile Survey

CMMI articles list in SoftDevArticles.com

(r) Capability Maturity Model, CMM, and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
(sm) CMM Integration is a service mark of Carnegie Mellon University.

When he joined Yahoo in 2004, the development process was mainly chaotic. Developers were producing software with “mostly” heroic attitudes and had to be available 24/24 to solve production problems. His first action was to put in place a traditional development process with control points. Local quality assurance teams were also created. This improved the quality of the delivered software. Asiatic teams were also pleased by the change. On the negative side, he saw some resistance from the UK teams that were already using Scrum. Some developers had also a tendency to “hide” themselves behind the process and escape responsibilities.

In 2007, agility was introduced in the organization, but not as a mandatory solution, because Alexandre Boutin thinks that you cannot force the people to be agile. The detailed process was abandoned for a process framework described on two A4 pages. The local quality people were transformed in agile coaches. The formal validations after each process stage were replaced by risk management checklists, not considered as “todo” lists, but to make sure that the team has examined all risk before moving to the next stage. All employees followed two days of agile training. As a consequence, Scrum was adopted by all European teams and used in some pilot projects in Asia. The transition to agile coaching was not obvious for all former quality people. An important regret was the missing of metrics collected during the previous years. This absence makes it more difficult to justify the change to the management with quality or productivity improvements.

Actions were taken in 2008 to help product (business) teams to work better with agile projects. Continuous integration was put in place with metrics to evaluate development teams:
* Velocity (inside the team only)
* Number of build successful or failed (build runs every two hours)
* Number of tests (but not test coverage)
* Number of bugs discovered during the first five days after a release.

In the positive results achieved during this transition, Alexandre Boutin mentions the good acceptance of the framework process. Scrum is also a considered a good project management approach, but it needs to be combined with good practices, especially for the testing activity. He recommends also to have a strong local coaching support and to train the developers again four to five months after starting doing agile projects. Development teams are now releasing new versions every four weeks, some of them aiming for a two-week release cycle. He has seen a strong improvement in people motivation and product quality. Culture seems to be the most important challenge to implement an agile approach in Asia. Hierarchical respect made it more difficult to carry the negotiation activities around the backlog. Daily-meetings done by phone for geographically distributed teams were also not successful. Finally, more efforts have to be made to assist the business users concerned by agile projects.

A word to remind: it is easier to “do” agile than to “be” agile.

* Top-10 Application-Design Mistakes
Application usability is enhanced when users know how to operate the UI and it guides them through the workflow. Violating common guidelines prevents both.

* Why Do I Need All That Process? I’m Only a Small Project
At Intel’s Information Technology (IT) department, we developed extensive processes for our projects. While the large projects get the glory, the majority of our projects are less than six months long, have small teams, limited scope, and low risk. We found that we have a variety of project sizes but a single set of processes originally built for larger projects. So how did we fix that issue?.

* Spiral Development: Experience, Principles, and Refinements
Spiral development is a family of software development processes characterized by repeatedly iterating a set of elemental development processes and managing risk so it is actively being reduced. This paper characterizes spiral development by enumerating a few “invariant” properties that any such process must exhibit. For each, a set of “variants” is also presented, demonstrating a range of process definitions in the spiral development family. Each invariant excludes one or more “hazardous spiral look-alike” models, which are also outlined. This report also shows how the spiral model can be used for a more cost-effective incremental commitment of funds, via an analogy of the spiral model to stud poker.