What if Your Software Development Vendor Wrote Your Custom Software Application for FREE?

Hello All,

Writing custom software is tricky business, especially in a typical customer/software development vendor scenario.  Whether using a more traditional waterfall model or some of the newest Agile techniques (e.g., Scrum) the process is fraught with risk for both the software vendor and the customer.  The customer is usually frustrated by the process due to cost overruns, scope agreement, schedule delays or all of the above.  The software vendor in many cases can experience financial losses and reputation hits that can threaten their very existence.

But what if the software development vendor wrote your custom software application for FREE? Would you sign a 3 to 5 year contract to let them host and maintain the software for a fixed-price per month or perhaps only charge you for the transactions that are processed by the system in a model similar to Software as a Service (SaaS)?  To clarify my meaning of custom software here, I am referring to business applications that are unique to a particular customer and not necessarily leveraged across multiple companies.

Would a paradigm that places 100% of the risk on the software vendor during the development of custom software be feasible if it also provided a complimentary reward model for the ongoing hosting, support and maintenance?  Here are some advantages that crossed my mind with this type of model.

• The burden is on the software vendor to get software up and running as soon as possible (since the vendor does not start getting paid until the software is functional) so time to market becomes paramount to the software vendor.  The only acceptable result is software that is running and available to the customer.
• Since the customer will not begin paying for the system until it is accepted and operational, the quality of the software must be at the highest levels.  The frustrating process of code, test, fix is no longer a typical customer experience.  The only thing the customer sees is operational code that has been considered acceptable.
• The software development lifecycle model is the choice of the vendor since only they control the effort.  Adoption of any particular approach (Agile, Scrum etc.) becomes a non-issue from the customer perspective.  The use of global resources to keep development costs low are also the choice of the software vendor since the customer is only concerned about the resultant application.
• Priority of features and functions that provide real business value to the customer will be the driver of the software development effort since the customer will only begin paying for those features and functions that represent true value to their business.  The vendor will be very sensitive to “wish list” features and will remove or defer them in place of the real value-adding functionality.
• Architectural integrity of the system must be at the highest levels.  A system that is not architecturally sound will create enormous costs to maintain and therefore will deteriorate margins over time.  However, a sound architectural foundation will ensure efficient and effective support of the system over time and provide the necessary profits to recoup the development expenditure and maximize the Return on Investment.
• This type of model should and would allow the software vendor to reuse components for other customers.  Obviously the intellectual capital of each individual customer must be protected, but if engineered correctly the software vendor can protect each individual client and at the same time build a significant portfolio of reusable components/features that will yield even greater rewards (read profit/margins) over time through more efficient software reuse.
• Since the software vendor is managing this as Software as a Service (SaaS), all of the operational details of the system (security, access, intellectual property protection, scalability, modifications, reliability, performance etc.) must be state of the art.  As long as the client has a browser, they have full access to the system and the assurance that it will be up and running and fully protected 24 hours a day, 7 days a week for one manageable payment per month, year or transaction.
• Ongoing support of the system (modifications, changes, phone support etc.) would be based on contractual service levels to reflect the business demands of the customer.  Again, in order for the software supplier to make money, these operations would be based on best practices and drive efficiencies and effectiveness throughout the life of the software system.
• Enhancements to the system would be based on the same model and will only add additional costs once those enhancements are operational.
• The customer will no longer have to increase staff to support the system once it becomes operational.
• In theory, the software vendor will continue to get better at their game.  The vendors teams will become more efficient, the software platforms used to develop and deliver applications will evolve with advances in technology as the vendor continues to drive efficiencies, and innovations created by the software development vendors will be passed on to customers in the way of declining development and support costs.
• Only software vendors that are exceptional in their trade could make this model work.  These vendors will have enough financial resources to “front” the development process and will have built the efficiencies of a well-oiled machine in order to ultimately turn a profit.  Firms that do not have a well-oiled operation will not rise to the occasion and theoretically only the strongest and best will survive.

Whether a model of this nature is possible will depend on specific contract language that will somehow lock the customer into the support arrangement assuming that the software vendor has done their job.  No software vendor is going to invest thousands or perhaps tens of thousands of dollars (dare I suggest millions) unless there is some assurance that their product will be accepted by the customer.  And of course the financial model must create a win/win for both the customer and the software vendor.

I would be interested in hearing your thoughts on this.  Have you had any experience with this type of model?  Do you believe this is even a viable business model?

I look forward to your comments.

Pete

Upcoming ITMPI Free Webinars

Hello All,

Here is a list of the upcoming webinars from ITMPI.  These webinars are FREE and can be accessed at the ITMPI Webinar site.

Enjoy,

Pete

Upcoming Webinars

---

Book Discussion: Pragmatic Software Testing

Presented By Rex Black

Computer Aid University (CAI-U) and CAI’s IT Metrics and Productivity Institute present a book discussion on Pragmatic Software Testing by Rex Black. In this insightful book, you learn more about the nuts and bolts of testing than most testers learn in an entire career.

With the help of real-world examples integrated throughout the chapters, you’ll discover how to:

• Analyze the risks to system quality
• Allocate your testing effort appropriately based on the level of risk
• Choose the right testing strategies every time
• Design tests based on system’s expected behavior (black box) or internal structure (white box)
• Plan and perform integration testing
• Explore and attack the system
• Focus your hard work to serve the needs of the project

We will briefly discuss the book and how Rex Black’s comprehensive training is uniquely suited to your needs.

 

November 23, 2009 4:00pm-4:30pm Eastern Time

---

Best Practices Integration – Lean Six Sigma and the CMMI

Presented By Gary Gack

Many organizations are challenged with integrating and leveraging various industry standards, including Lean Six Sigma, PMBoK, ITIL, and CMMI. Our presenter, Gary Gack, brings a deep understanding of these best practices and in this webinar clearly explains connections and synergies between Lean Six Sigma and the CMMI. A case study that leveraged both LSS and the CMMI is presented.

November 24, 2009 11:00am-12:30pm Eastern Time

---

Deception and Estimation: How We Fool Ourselves

Presented By Linda Rising

Our estimates are best guesses, so we continually re-evaluate as we go, which is an agile approach. In many plan-driven development projects, people try to make the best estimates possible and use “scientific” approaches – all for naught. In this webinar, Linda Rising demonstrates how hard it is to see our poor estimating skills and describes how to avoid self-deception.

December 1, 2009 11:00am-12:30pm Eastern Time

---

The Business Case for Software Process Improvement

Presented By Allen Bennett

The Software Engineering Institute (SEI) maturity models are now twenty years old. There are many examples of the cost benefits of implementing the best practices in the maturity models. This webinar with Allen Bennett will examine the costs and benefits of several specific best practices. The data for this presentation comes from the experiences of ITT Corporation.

December 2, 2009 11:00am-12:30pm Eastern Time

---

Using Function Points For Economic Analysis of Software Methodologies

Presented By Capers Jones

This webinar with Capers Jones shows how standard “test beds” using function points can be used to evaluate software methods. The webinar describes a standard analytic approach for evaluating the effectiveness of emerging technologies on software development and maintenance productivity and on software quality. Capers also discusses uses of function points for portfolio analysis, backlog analysis, mergers, and outsource agreements.

December 3, 2009 11:00am-12:30pm Eastern Time

---

Application Knowledge Capture: A Method for Preventing the Loss of Critical IT Knowledge

Presented By Nick Spanos

The baby boomers are retiring faster than ever, critical IT application knowledge is moving off-shore at an increasing rate, and the work force is more mobile now than ever before. Who is going to be left behind to mind the store? This webinar by Nick Spanos will outline a methodology for capturing such knowledge before it is too late.

December 8, 2009 10:00am-11:30am Eastern Time

---

Incremental Value-Focused Optimization for Your Configuration Management Database

Presented By Ahmad K. Shuja

Optimizing your configuration management database (CMDB) can be an expensive proposition. To maximize return on investment, CMDB optimization needs to planned and executed in an incremental and value-focused manner. This webinar by Ahmad K. Shuja presents the Incremental CMDB Optimization process, which will ensure that CMDB optimizations are carried out in a controlled and targeted manner.

December 9, 2009 11:00am-12:30pm Eastern Time

---

Please note that all webinar times are displayed in US Eastern Time.

How do you recognize individuals in Agile/Scrum?

Hello All,

I have been thinking lately about a question that someone posted on a LinkedIn Group discussion.  His question was “do you recognize individual performance in Scrum?”

Many of us are somewhat predispositioned to a culture that rewards the individual.  You might call this type of model a meritocracy and one of the goals of management in this type of model is to reward those that regularly excel in their jobs.  By doing so, this serves to create a model of excellence for all team members..

Enter Agile and Scrum.  One of the key principles in Scrum is the self-managed team.  The team operates as one to move the project to completion.  They work together to make decisions and drive results.  The key Agile principle that governs this as stated in the Agile Manifesto is to “build projects around motivated individuals, give them the environment and support they need and trust them to get the job done.”

Although there is a lot of attention paid to the entity of the team in an Agile/Scrum project I also believe that to create “motivated individuals” that individual recognition and reward is essential.  The difference, however, rests in who does the rewarding.  In more traditional management styles, it is typically a project manager that selects the individuals that will be recognized.  Sometimes this can be a bit subjective and can actually create more animosity than motivation.

True motivation and satisfaction however will be achieved when individuals are recognized by their peers.  Therefore, I recommend that in keeping with the principles of Agile that the TEAM selects and rewards the individuals to be recognized.  One thought is to create a program of “Sprint Champion.”  After the completion of each sprint, the Scrum team votes for the person that contributed most to the Sprint.  The voting should be based on a set of performance criteria established by the team prior to the first Sprint.  A sample list of criteria could be:

• Contribution of ideas that led to the success of the sprint,
• Amount of assistance that a team member contributed to other team members in helping them achieve their goals,
• Accomplishment of work based on the contribution to the overall team velocity,
• Innovation in solving difficult problems,
• Enthusiasm, and
• Encouragement to other team members

Again, this list of criteria should be established by the team and there should be a budget that is managed by the team for each Sprint in order to recognize the Sprint Champion.  This could be distributed as cash bonuses, prizes, plaques and recognition parties.

I would be interested to know how your Agile/Scrum team recognizes individual performance?

Pete

Flock or Fleece?

Hello All,

On my blog roll there is a link to the Be Good Ventures: Joe and Wanda blog site.  I found a recent blog post on the site entitled Flock or Fleece.  I found the following entry on leaders to be a very appropriate description of any leader or manager, and certainly for a Scrum Master.

“Effective leaders are those interested in the flock – the people they are leading. They see their role as that of a giver – to get behind their people and support them in ways that bring out their best.  Ineffective leaders are interested only in the fleece and couldn’t care less about their flock – they’re takers… The lesson here is to be a giver and show an interest in your flock.  If you do, your flock will respond in ways that will guarantee your success as a leader.”

See the book Instant Turnaround, by Harry Paul and Ross Reck.

A good Scrum Master fits this description in that they are interested in the flock – the people they are leading.  They define their leadership role in terms of the others that they lead.  They facilitate the productivity of the individual team member and thereby the productivity and success of the whole team.  They seek to remove obstacles that would make the team members unproductive and they serve the team members by lifting them up, promoting their strengths and recognizing them and the team’s accomplishments.

As a Scrum Master, ask yourself the question: “Is my behavior demonstrating my concern for the flock or for the fleece?”

Pete

Why Being a “Good” Manager is “Great”

Hello All,

A colleague of mine has written a book called “Lead Well and Prosper”.  It is a common sense guide that provides 15 successful strategies on becoming a good manager.  It is written from the voices of Joe Kerr and Wanda B. Good.  They provide entertaining, humorous and yet important insights into becoming a good manager.  I read the entire book in one sitting and truly connected with the lessons in each chapter.

From the Be Good Ventures Website:

As the author points out, most managers don’t aspire to mediocrity;  they
just don’t work on the right things.  This book not only shows them what
those “right things” are, but it offers practical, ready-to-execute actions and
solutions.  In this unique resource, you’ll learn:

• How effective it is to get “back to the basics” of managing
• Why being a good manager is great
• Straightforward strategies you can implement immediately
• The dos and don’ts of management success.

Please understand that I do NOT promote books or products for any personal gain on this blog site.  If it is posted here it is because I believe you will find it worthwhile. So check out Nick McCormick’s book.  You can access it here:  http://www.begoodventures.com/Book.html.

Also check out the Joe and Wanda Blog Site at http://begoodventures.com/joeandwanda/

Enjoy your weekend!

Pete

Can Agile be Combined with Offshore? 12 Lessons Learned.

Hello All,

One of the readers of my blog recently asked a very good question.

“Can Agile be combined with offshore?”

Although my initial response is “Yes” it comes with some conditions.  One of our projects recently utilized a partner in India.  We had used this partner successfully in the past for some non-Agile development work, but we quickly discovered that Agile, and in particular Scrum, was a game changer. Our first few Sprints did not go very smoothly.  We found out that blending offshore with an Agile project being run domestically took a greater degree of management and communication than we would normally apply.  Once we realized that there was a higher level of overhead required to make this work we were able to get the project back on track.

I sat down with the development manager responsible for this project and asked him what the critical success factors were in managing a project that had some component of offshore.  He provided a set of 12 “key lessons learned” that might be of some help if you are embarking on using an offshore team for your Agile/Scrum development efforts.

Lesson 1: Make sure you have an overlap of at least 2 hours for your onshore and offshore teams’ working day, if possible.  Since India is nine and a half  hours ahead of us during daylight savings time, we were able to construct a two hour overlap in our schedules in order to conduct the daily stand up meetings and resolve any outstanding issues.  This greatly increased the communication flow and cohesiveness of the teams.

Lesson 2: Create a robust repository and collaboration site that will be the site of record for all specifications, test cases and discussions.  We used SharePoint for this which became the repository of record for all communication, collaboration and storage of critical artifacts of the project.

Lesson 3: Do not use email as your primary method of communication (email is still a good mechanism for communication, but should not be used for discussing important topics such as requirements clarification or design decisions).  Ensure that all communication is conducted through the repository so that it becomes a permanent record of events, artifacts and communication.

Lesson 4: You should implement web conferencing to create a sense of proximity of team members.  We used this on a daily basis to conduct stand ups, review wireframes and specifications, walk through requirements and conduct Sprint reviews.

Lesson 5: Have one central point of entry for project status.  All team members would record their progress via a central Scrum management tool.  We used ScrumWorks as our tool of choice and were able to create accurate product backlogs, Sprint backlogs and burn-downs on a daily basis.

Lesson 6: Ensure that your offshore team has their own development and test environments, bug reporting tools (Bugzilla in our case) and source code repository.  In our case, all of the development was being conducted offshore, so we found it better to have the offshore team in complete control of the development and test environments.

Lesson 7: Shorten your Sprints.  We typically do 4 week Sprints when we conduct a project domestically. We discovered that we needed more frequent inspection and visibility into progress so we shortened the Sprints to 2 weeks.  This made course corrections much easier and facilitated greater communication of requirements, more accurate status reporting and more meaningful reviews with the customer.

Lesson 8: The Scrum Master must be top notch.  Our Scrum Master was located in the United States as well as the Product Owner.  The Scrum Master is the key arbitrator in all Scrum projects but we discovered that it took a greater level of skill and experience to facilitate a Scrum when using offshore resources.  This cannot be a training ground for aspiring Scrum Masters.  You must assign your best to handle an offshore project.

Lesson 9: If possible, your Scrum Master should speak the languages of both your onshore and offshore team.  The more they understand the language and culture of the dual teams, the greater the communication flow and understanding of the project requirements.

Lesson 10: The Product Owner must clearly define what “done” means for each of your user stories.  In an offshore model we do not have the luxury of walking down the hall to refine and iterate.  Well- defined acceptance criteria should be included in all of your user stories.

Lesson 11: There must be a strong technical leader on the offshore team.  Your offshore team must possess all of the technical skills to be self sufficient.

Lesson 12: The offshore team must be properly trained in Scrum and specifically in your particular implementation of Scrum.  It is worth the cost and time to travel to the offshore site, get to know the teams and properly train them for one or two Sprints to ensure that all expectations and processes are well understood by the offshore team.

Additional thoughts on running an Agile project using offshore resources can be found in an article written by Martin Fowler.  The article can be accessed at:

http://martinfowler.com/articles/agileOffshore.html

I welcome the thoughts and experiences of others that have utilized offshore resources in an Agile development framework.

Have a great day!

Pete

————————————————————————–

Special thanks for Mr. Jim Dempsey for his contribution to this article.  Jim is an Account Manager and Practice Manager for Application Development and Quality Assurance at CAI.  See his profile on LinkedIn.

Blog Articles Summary

Hello All,

Here is the list of the blog articles listed in the last 45 days.  In addition, I have added a number of sites to my blog roll and other relevant links to sites that you might find informative.  I will be adding 2 or 3 more blog articles next week so stay tuned.

Have a great weekend!

Is Scrum Too Simple: Comments From You! Got a ton of comments on this article.  Here they are!

Scrum in Under 10 Minutes! You Tube Video Great YouTube Video that Teaches the basics of Scrum in under 10 minutes

Is Scrum Too Simple? Is the simplicity of Scrum an obstacle to adoption?

The Personality of a Great Scrum Master – A Recap Summary of the comments received from the readers.

Friday Agile Humor Scrum Master job description from one of the readers.

Great Blog on Fixed Price Agile Self explanatory!

The Personality of a Great Scrum Master What makes a Great Scrum Master…This one got a lot of comments.

Addendum to Agile Fixed Price Software Development Money for Nothing and Your Change for Free – Jeff Sutherland

Agile Fixed Price Software Development A Framework for a Fixed Price Agile Project

The Road to Service Management Transformation: Visibility, Control, Optimization IT Service Management Transformation

Twitter: A Business Model Evolving? Is Twitter Really worth 1 Billion Dollars?

Agile Adoption is Hard! Ask the Right Questions. Great Article I found on AgileSoftwareDevelopment.com.  A must read for anyone struggling with the adoption of Agile.

Product Owners – The Guardians Here I provide some insight into the true role of the Product Owner on an Agile Project.  More than just a liaison between the Scrum team and the business, The Product Owner should be the “guardian” to ensure that the target application system is delivering TRUE business value.

Lipstick on a Pig? Calling all Agile Practitioners! I am trying to gather up real life experiences with Agile methods.  In this blog article I am calling all Agile Practitioners to provide articles/short stories/ ideas and thoughts on what they have found to be the greatest contributors to success or the risks in making Agile successful.  Please read and provide me with your thoughts.

Software Risk Management At the heart of a successful project is a comprehensive Risk Management Program.  I discuss some of the features of a Risk Management program and lead you to a number of articles that discuss this complex field in greater detail.

Friday Afternoon Software Development Project Humor I found a witty article by Dr. Robert Charette on the ITMPI website.  It takes a humorous look at attitudes in handling a difficult project while really making you think.  Check out the article “How to Create a Successful Failure”.

Agile Adoption = Mental Shift In this article I discuss how the adoption of Agile takes more than just creating Scrum teams, burn-down charts, daily stand-ups etc.  You must first make a mental shift about how you think about projects.

Is Scrum Too Simple: Comments From You!

Hello All,

The article Is Scrum Too Simple has won the contest so far as having generated the most activity from you, the readers of this blog.   The article had over 50 comments ranging from “Yes…It is too simple”, to “No, it is actually quite complex and difficult to implement. ” Since I post the discussions in several LinkedIn groups not all of the comments make it to the actual blog site.   So, I wanted you to have the benefit of all the comments that I received.  I have included them, unedited, as an MS Word file and made it available to you for download.  It can be accessed on the right panel of this blog.  It is a blue box labeled “My Shared Files.”  Click on the file labeled “LinkedIn Group Discussion on Is Agile Too Simple.doc.”  then just follow the instructions to download the file.  Some of the comments received were:

• “As Albert Einstein said: “make everything as simple as possible, but do not make it over-simplistic. (my interpretation)”.   No method can be TOO simple – unless it becomes over-simplistic and, as a result, too abstract.
• “I think that saying that Scrum is too simple has the underlying assumption that it ever was intended to be complete. It never was, it never will be: it’s intentionally as small as it is.”
• “My 2 cents is that even the agile … a la Scrum, can actually be simplified even further. It’s a good time to re-examine what works in particular organization and may not work in others.”

There are a lot of pretty interesting ones in there so enjoy.  Again, these have not been edited except in one or two instances where the meaning would not have been clear.

I have not quite gotten my arms around all of them yet, but I do plan on consolidating these comments into an article next week.  Stay tuned!

In the meantime…keep your thoughts and ideas coming!

Pete

Follow me on Twitter at www.twitter.com/peterdeyoe

Scrum in Under 10 Minutes! You Tube Video

Hello All,

Many of you may have seen this but I thought I would post it for those of you that do not have an understanding of how Scrum Works.  The YouTube video was produced by Hamid Shojaee.

Enjoy,

Pete

Is Scrum Too Simple?

Hello All,

I have had the opportunity to meet with a number of IT leaders in that last couple of years to discuss with them the adoption of agile practices in their organizations.  In all of the meetings I have had I do not remember a time when someone actually overtly disagreed with the concepts of agile and particularly scrum.  They have, however, questioned whether agile would work within their particular organization.  Agile’s perceived lack of documentation and defined/written processes, simple framework and seemingly ad hoc approach to development have all been cited as going against the grain of their typical organizational practices.

This has made me wonder over the years if agile and particularly scrum is too simple.  Is scrum’s perceived lack of rigor an obstacle to adoption by most large companies? Is the simplicity of agile, which makes it such a malleable framework to accommodate change, actually a barrier to adoption?

Many of us older IT practitioners were schooled in practices that had rigorous processes, extensive documentation, detailed quality audits and excessive measurements that have predispositioned us to believe that only complex methodologies will lead to success.  It sometimes seemed, in the old days, that the more detailed a methodology, the more trusted and respected it became.  I also wonder if in fact IT practitioners created an entire industry around complexity.  Let’s face it, the more esoteric the domain, the greater the level of job security for those within the confines of that domain.

So now we are introducing simplicity, perhaps simple enough that “even a caveman can do it.”  (I am not suggesting that adopting agile is easy, only that it provides a relatively simple framework that is easy to understand).  Is this message a threat to traditionalists?  Is the real barrier to adoption one that stems from individual and organizational self preservation?  Have we become too comfortable in our minutia that we are unwilling and unable to accept and try alternatives?

As always, I welcome your thoughts and comments.

Happy Sunday!

Pete

The Personality of a Great Scrum Master – A Recap

Hello All,

There was quite a lot of activity this week on the discussion board for this blog.  There were over 20 comments made on the article The Personality of a Great Scrum Master.  In the article I offered some suggestions as to the personality traits that a great Scrum Master should possess and suggested that it is difficult for a “traditional” Project Manager to make the shift from a “command and control” world to one of “self managed” teams.

Well, much to my surprise I had a number of readers that took issue with this latter point.  Many of the readers came from more traditional project management roles and had made the conversion to scrum.  A wide majority who commented felt that the specific characteristics that make a great Scrum Master are also the ones that make a great Project Manager regardless of the methodologies employed.  One reader commented on my suggestion that a traditional Project Manager will approach projects from a “command and control” perspective was “short sighted” and that this kind of management approach is an example of “bad project management”.  He suggested that what makes someone a good Scrum Master is “just to be a good Project Manager”.

Another reader suggested that a Project Manager’s role (whether in scrum or more traditional projects) is to remove obstacles, manage risk and issues, and foster the right environment for the team members to do their jobs and he finds it liberating NOT to create a “command and control” environment.

A third reader wrote that whether scrum or more traditional methods, the core skills of strong facilitation, planning and communication skills are the skills that we should demand from our professions “and by not doing so we only undermine the overall relevance of project management as facilitating organizational strategy.”

There were also some humorous comments (although I am not sure they were necessarily intended to be).  One reader suggested that a Scrum Master is “one that doesn’t have a PMP.” Ouch!  And of course there was the job description posted by Charlie Rex from Australia that I blogged about yesterday entitled Friday Agile Humor.

And finally, one reader brought to our attention that both Ken Schwaber and Jeff Sutherland have publicly stated that “professional Project Managers (PMPs) make the best Scrum Masters” and that “scrum does not replace the PMBOK (Project Management Body of Knowledge) but that they actually complement each other.”

Now, there were a few folks that agreed with me on the point.   “It’s a tough role for people who are used to being in charge” is what one reader suggested.  This was agreed upon by another reader who said that “the Scrum Master isn’t the typical leader person.  You are required to be more of a social chameleon.”

Another mentioned that he had been both the “traditional Project Manager” and who now travels the world training people on scrum.  He said that “even (he) has problems not going into ‘command and control’ mode.”  He suggested that it “takes constant introspection and discipline, and is something that does not come naturally to (him).”

So what do I make of all this?  Well, first of all, I am starting to figure out how to make people come out of the woodwork and post their opinions!  Seriously though, I am delighted that there was such contribution of ideas.  After all, that is what blogging should be about: collaboration of ideas that lead us to truths that further the advancement of our industry.

I still contend that traditional Project Managers that were indoctrinated in a more “command and control” environment (whether rightly or wrongly) and/or are naturally bent toward authoritative leadership will have a difficult time not being in charge.  In scrum, the team must take control of the project as a team.  In the words of one reader, The Scrum Master must “know when and who to give a nudge, not for the sake of feeling in control but to keep the team moving forward, and (he/she) must know when to let someone else hold the torch.”

But what I have learned from all of the contributors is that this is more about the individual and less about traditional project management.  Anyone that is open to new ideas, seeks new ways of operating that will ultimately lead to success, fosters a strong team environment, displays humility, and checks their egos at the door will be a successful Scrum Master.

Have a great weekend!

Pete

P.S.  There were a number of articles and sites that the readers submitted along with their comments.  Here is a partial list for your convenience.

http://www.implementingscrum.com

http://www.agile42.com/cms/articles/?section=press-releases

http://www.thehackerchickblog.com/2009/09/agile-leadership-methodology-ain-enough.html

Friday Agile Humor

Hello All,

The article I wrote on The Personality of a Great Scrum Master has received a fair amount of attention.  In fact between the discussion threads I started in my LinkedIn groups and on my blog there were over 20 comments on the article.  Some of them in agreement; many of them taking issue with the idea that a traditional Project Manager may have a difficult time making it as a Scrum Master.  My intent today is not to really go into that.  I will actually be pulling the comments together and summarizing them in an article this weekend.  Stay tuned!

In the meantime, I just had to share with you a little Agile Humor.  A reader posted a comment on one of the LinkedIn groups and I found it to be pretty funny, yet poignant.  I thought I would share it with you.  It helped me realize that I cannot always take the topic too seriously.  Hopefully you will find it amusing.  If not I am sure you will post your comments and let me know.

From our mate down under, here is the post from Charlie Rex of Melbourne Australia (you can visit his site at www.ThomsettInternational.com).

————————————————————————————-

WANTED – SCRUM MASTER

JOB DESCRIPTION:

Stand in front of a group of (sometimes) rowdy, opinionated techos and business people who have important overt agendas and ‘real’ covert agendas; and keep the peace while facilitating an amicable arrival at a consensus regarding the project being considered. All the while ensuring that any ‘Big Cheeses’ present do not get bored and leave; or worse yet, dominate the discussion if they stay.

SKILL SET:

• Eyes in back of head.
• Able to walk, talk, listen, write, smile, nod and think all at the same time.
• Can recognise a big ego from 20 paces and not stomp on it (too hard).
• Can smell a covert agenda from two rooms away.
• Knowledge of the Scrum process essential.

THE SUCCESSFUL APPLICANT:

• Must not appear to be more opinionated than techos and business people. Indeed, must be able to demonstrate complete impartiality regarding the project at hand.
• Will have well honed people skills and will continue to develop those skills.
• Will wish to contribute hugely to the success of the project and the business.
• Will wish to have fun.

Enjoy,

Pete

Great Blog on Fixed Price Agile

Hello All,

Check out this article on Bobtuse Bobserations blog.  Good discussion on Fixed Price Agile Projects.

http://bobtuse.blogspot.com/2009/02/fixed-bid-bane-of-agile.html

Pete

Some Upcoming Webinars from ITMPI

Hello All, Just wanted to make you all aware of some upcoming FREE webinars from ITMPI.  I have received a number of posts recently that the webinars were valuable. You can take advantage of these by registering at the ITMPI site. By attending you can receive PDU points as well. Silver bullets – Do They Hit the Mark? Presented By Peter Hill The ISBSG has performed extensive analysis of project development tools and techniques. In this webinar Peter Hill looks at the impact of these tools and techniques on development productivity and reviews the impact of using a methodology, of being CMMI or ISO compliant, as well as the techniques of Modeling, Prototyping, Rapid Application Development and Object Oriented Analysis and Design. October 26, 2009 4:00pm-5:30pm Eastern Time

Boosting Performance in Small Organizations with the CMMI Presented By David Walker If you don’t think the CMMI can scale to small organizations, then you must attend this webinar. David Walker will lead you through an analysis of the important environmental parameters, innovative and proven strategies, and lessons learned in applying the CMMI in small software development organizations. October 28, 2009 11:00am-12:30pm Eastern Time

Maintain Your Success By Using the Best: Using CMMI & ITIL to Become Excellent at Maintenance and Support Presented By Larry Dribin CMMI and ITIL can be used together to improve maintenance and support activities. In this webinar with Dr. Larry Dribin, you will learn how the integration of the CMMI and ITIL can provide an excellent process foundation to guide the maintenance and support organizations to improve their performance and achieve IT Excellence. November 3, 2009 11:00am-12:30pm Eastern Time

The Personality of a Great Scrum Master

Hello All,

In the ezine article Scrum Impediments, the author Laszlo Szalvay, President, Danube Technologies, Inc. discusses the vital role that the Scrum Master plays in ensuring team success through the elimination of impediments to an Agile-Scrum based project.  The Scrum Master role is not the typical project manager role that we have become accustomed.  This role, rather than focusing on just the mechanics of project management, planning and execution, is geared to being the ultimate team advocate, protector of team productivity, facilitator and communicator.  This is not to say that a good project manager does not assume these roles.  It is more to say that these are of primary importance in the Scrum Master role.

But what characteristics make for a great Scrum Master?  A blog posting by Jim Trott on the website NetObjectives identifies 4 key characteristics that are present in a great Scrum Master.  He states that the Scrum Master must:

• Be humble enough to serve the team;
• Have a strong character and be confident enough to stay in the background, promoting the team;
• Display a high degree of integrity and maintain a trusting relationship with all the team;
• Be politically savvy with a strong relationship with the Product Owner, and;
• Be able to understand both business and technical people.

It has been my experience that the more traditional project manager has a difficult time adapting to the role of Scrum Master.  Command and control is the modus operandi in traditional projects and project managers have been indoctrinated within this paradigm.  But with Agile and in particular, Scrum, self managing teams are the norm.  This requires a unique mindset.  The Scrum Master must serve the team as a coach.  They must not direct, but rather facilitate team self management.  They must function as a single voice to the business and technical community on behalf of the team.  They must protect the team from extraneous “project noise”.  They must be motivators and must always cultivate an environment of trust and good faith.  They must have the courage to stand up to the business and IT community to ensure that the principles of agile are being upheld, that short cuts or hybrid models don’t begin to emerge due to executive management pressures and that the team is shielded from politics and bureaucracy.

What has your experience been?  If you have had (or are) a particularly strong Scrum Master, what made them (or you) stand out?  If you have had the opposite experience, what were the weaknesses that should have been identified before putting the person in that position?

As always, I look forward to your comments.  You can post your comment here or you can email me at Pete@TheDeYoes.com.

Have a great day!

Pete

Follow me on Twitter at www.twitter.com/peterdeyoe

Addendum to Agile Fixed Price Software Development

Hello All,

Just a quick note here to supplement the article I posted yesterday on Agile Fixed Price Software Development.  In doing more research on the topic I stumbled onto this article entitled: Money for Nothing and Your Change for Free by Jeff Sutherland.   Very interesting approach to some potential contract language and the responsibilities of each party.  I particularly like the description of the customer participation and their ability to make changes and the Early Termination clause which supports the idea I posted yesterday that we have to give the customer some lever of control.

Enjoy,

Pete

Follow me on Twitter at www.twitter.com/peterdeyoe

Agile Fixed Price Software Development

Hello All,

I have been reviewing a number of articles and blogs recently dealing with the question: “Can you do fixed price software development using an agile approach?”  On one post in a LinkedIn group recently the participant wanted to know if you could do fixed price development and still adhere to the principles of agile.  I responded to the post by sending an article from RichardsBraindump that provided some ideas as to how you could pull this off.  And although I do agree with a number of the points in the article, I wanted to expand a bit on the topic.

As agile practitioners you understand that in terms of the Iron Triangle that you can fix schedule and cost, but that scope must flex.  You are indoctrinated in the core principle that you can complete a certain amount of work in a fixed time period (a 4 week sprint for instance).  This in turn will translate to a fixed budget to complete some amount of work within that time period.  If it looks like you will not complete the initially targeted scope within that time period, you drop out scope in favor of honoring the time and cost commitment.  The result is that you finish your 4 week sprint on time with a working, tested and production-ready piece of the software puzzle but the omitted scope goes back on the product backlog to be reprioritized for subsequent sprints.

In a typical fixed price contract where all sides of the Iron Triangle (schedule, cost and scope – with quality being constant) must be met, this looks like the project is slipping.  And of course, if scope is not flexible, then in fact, it is.

The rub lies in the fact that in the eyes of the agilest, deferring scope from one sprint to the next is a natural result of the agile process.  However, in the eyes of the business leader and IT leader responsible for the delivery of the software to the business, the project is in trouble if you continue to defer scope from one sprint to the next.  The Agilest is of the mindset that not all of the scope defined in the initial project backlog will actually be developed (only the highest business value features), yet in the mindset of the business, the definition of done (in a typical fixed project) is when all scope defined in the initial project backlog is complete.  So how do you reconcile this?

My first piece of advice is this:  If the business or customer cannot accept the idea that not all of the features specified on the initial project backlog are truly necessary to deliver business value, insisting rather that the definition of done is when all of the items on the product backlog have been completed, then you should politely decline to take on the project.  If there is one thing that I am absolutely sure of, there will be no way to reconcile this difference and meet all of the quality, scope, timing and cost constraints of the project.

For those of you that have ever “taken a bath” on this kind of project (and I feel confident that many, if not most, of you have) then you understand what I am talking about.  I think it has been well established in the industry that there is no way that a project in the early phases can be estimated with any degree of accuracy.  The Cone of Uncertainty has been well documented.  On the Construx.com website the authors state that:

“As you can see from the graph, estimates created very early in the project are subject to a high degree of error. Estimates created at initial concept time can be inaccurate by a factor of 4x on the high side, or 4x on the low side. “

And;

“An important– and difficult– concept is that The Cone of Uncertainty represents the best-case accuracy that is possible to have in software estimates at different points in a project. It is easily possible to do worse. It isn’t possible to be more accurate; it’s only possible to be more lucky.”

So, with this in mind you can safely say that what you know in the early phases of any software development project is that your estimates can be wrong by at least a factor of 4, and possibly even worse.  If you attempt to build a fixed price contract based on this reality then several things can happen.

• You will have to significantly inflate your contract price to accommodate this reality.
• You will “low-ball” the price in the beginning and hope to make up for the difference by creating an iron clad contract with caveats and arcane contract language that will lead to “nickel and dime” changes throughout the life of the contract.  This of course creates nothing but frustration on the part of the customer/business and pushes the project end date into the dark abyss.
• You will simply “lose your shirt” trying to satisfy the requirements of the project if you are not lucky.
• Quality will suffer greatly as you try to short-cut the effort to preserve your financial condition.

OK, so now the partnership and collaboration speech.  Hillary Clinton is famous for her book “It Takes a Village”.  I realize that she was not referring to software development, but to create value-rich, high-quality software, it really does!  Your customers and businesses must be co-conspirators in the quest for developing high quality, value-focused software.  They must be indoctrinated in the principles that lead to software development success.  They must understand and embrace the fact that the definition of software in the early phases of a project is loose and ambiguous and that only iteration after iteration will drive them closer to the clear definition that they seek.  They must embrace the fact that software drives business value over time and is evolutionary in nature.   In an earlier post on my blog ( Agile Adoption = Mental Shift) I stated that:

“A second agile adoption principle that must be embraced requires businesses to stop thinking about software projects with defined beginnings and endings, and think instead of software applications as living, breathing, business-value delivery systems.  Businesses must understand that business value delivery through software is evolutionary.  As the business changes, so does the definition of business value and so must the software applications that deliver that business value. “

I highly recommend that before engaging your client in any fixed price agile project that there be a period of indoctrination as to the principles of agile and an unwavering commitment from the top of the organization to those principles.  As agile practitioners, within your portfolio of services you must have an extensive education program that focuses on the key elements of agile adoption and deliver this education to all levels of the organization involved in the software development effort.  Yes, this means culture change!  Agile requires the right business climate to flourish, and like all living things, it will die outside its normal and life sustaining habitat.  Again, if this cannot be accomplished then you are better off declining the project.

Now, with the stage set and the right mix of life sustaining ingredients in place, you can begin to construct a program based on time-boxed cycles, budget commitments and TRUE value delivery to the organization.

Here are the steps that I recommend in constructing a fixed price engagement within an agile framework.

• It is assumed that the period of indoctrination was completed successfully and that the organization has or is adopting a culture conducive to agile software development.  In order to secure the business this might be a FREE or low-cost service that you provide.  Some businesses may be willing to pay, others may not.  If the software development effort is large enough the cost could be absorbed during the duration of the effort.
• Assist the customer in defining the level of expenditure that they are willing and able to spend in a given period of time for the delivery of business value driven software.  In my article Agile Adoption = Mental Shift I stated that:

“In order for Agile to work successfully, we must stop asking the following question:

‘We have all of these needs and wants for the new system that have yet to be defined in detail but can you tell me precisely how long it will take and how much it will cost?’ (Traditional fixed-price model).

Instead, businesses looking to adopt an agile software model must shift their thinking and begin rephrasing their question as follows:

‘I can afford to spend $1,000,000 of my budget this year on the development of new software that will add value to my business.  How much real business value can I deliver this year for that level of expenditure?’”

• Conduct a series of sessions that are focused on developing the initial product backlog.  This should take about 2 weeks of elapsed time working with the business and stakeholders.  You can time-box this into four, one day sessions within the 2 week period and charge a fixed price for the 2 week assessment.
• Once the project backlog has been created, begin the typical product backlog prioritization activities.  In my experience you can conduct 2 working sessions (1 day each) to arrive at a well prioritized list.  Again, this can be time-boxed and delivered for a fixed price to the customer.
• Now create your initial estimates for all of the features on the product backlog list using your relative-value estimating techniques.  I’ve typically seen the use of user stories and relative- value story points as feature set and estimating vehicles.
• Commence a 2 sprint discovery period (typically 4 week sprints, but 2 weeks is acceptable as well). This discovery period provides you with the baselines you will need to establish your core architecture, coalesce the team, and baseline your team’s velocity (throughput) and estimating accuracy.  It will eliminate a certain amount of uncertainty out of the blocks and establish the core metrics that you will need to provide your fixed cost.  Again, fix the cost of the 2 sprint effort to the customer.
• Since uncertainty of estimates is a reality, especially in the early phases of a project, you must calculate an uncertainty factor.  One way to arrive at this is to assess the accuracy of your estimates during the discovery phase.  Since you should be tackling the most complex aspects of the project first (the most complex or unknown features should be at the top of the product backlog) you should be able to arrive at a reasonable uncertainty factor.  During your first sprint planning session, you should re-estimate the features contained in Sprint 1.  Compare these to the initial product backlog estimates.  If there was a 15% difference between your original estimates and the first sprint estimates, log this as your initial uncertainty factor.  Then as you begin Sprint 2, go back and determine, based on the actual completion of Sprint 1 what your actual Sprint 1 estimates should have been.  Let’s suppose that the comparison showed, based on learning’s that the uncertainty factor was 20%.  Now do the same with Sprint 2.  Let’s assume that the uncertainty factor for Sprint 2 was 25%.  Use the greater of the values to determine your uncertainty factor which would be 25%.
• Now that you have a budget number, an estimate for the overall project in story points, an uncertainty factor and an estimated team velocity, you can now begin drafting a contract with the customer.  You can derive your costs to conduct each sprint based on the velocity.

Let’s assume that the budget for the project is $1,000,000 and after 2 sprints your average velocity is 100 story points per sprint.  Let’s now apply the estimating uncertainty factor of 25%.  If the originally estimated points in your product backlog were 1200, then it will, in theory, take you 12 sprints to complete the effort at a cost of, let’s say $100,000 per sprint.  Now, since you have already reduced the backlog by 200 story points during the discovery sprints (at roughly the cost of $200,000), the backlog is now only 1000 story points and the new budget number is $800,000.  If you then add the uncertainty factor of 25% to the remaining story points, the new story point estimate is now 1250.

On the surface, this would put you in an over budget situation (roughly $1,250,000).  However, because you have prioritized the list to deliver the highest business value features first, and you have come to agreement with the Product Owner/business that a certain percent (let’s say 70% for this example) of the total remaining project backlog represents the features and functions that will deliver what the business truly needs to increase revenues, lower costs etc., then the magic number to complete the highest value components is 875 story points (1250 x .70).

You know that your velocity is 100 story points per sprint so you can feel relatively confident that you can complete the remainder of the effort in 9 sprints (8.75 sprints rounded) at a cost of $900,000.  However, since we have already used up $200,000 of the budget, we are still over budget by $100,000.  The customer must either increase his budget to $1,100,000 or you must reduce the number of story points and consequently the business value that you can deliver (unless of course you want to compromise your financial position to meet the customer’s needs which is always an option).  For the purposes of this exercise let’s assume that the customer is willing to increase the budget to $1,100,000.

So these are the magic numbers that you base your fixed price contract.

For the fixed price of $900,000, we will deliver to the business the remaining 875 story points, that at least at this point in time; represents the core business value that the software system must deliver.

Now for the controls!  What you are agreeing to with this contract is to deliver 100 story points worth of features each sprint (on average) that have been developed, tested and accepted by the customer.  The definition of completed story points in Agile is that they are potentially production ready.  The onus is on you and your team to live up to that commitment and the associated costs to deliver this will be on you and your team, not the customer.  So, it is imperative that you have a “well-oiled machine” that can deliver this consistently.  A subpar team will put you in a losing situation.  You must know what you are doing and your team must operate with the greatest level of efficiency and effectiveness.  If you cannot deliver this then you should consider an alternate vocation.  Selecting the right initial velocity is important.  The good news is that as your team completes sprints, the velocity should improve over time.

If you are up to the challenge, then a couple of key ingredients must be in place.  The Product Owner, typically a Sr. Business Level or Project Management professional that embraces the principles of agile and understands true business value must be a full-time contributor to the project and represent the business at all times.  This is typically an employee of the company that has direct reporting responsibility to executive management.  (See my blog posting Product Owners – The Guardians).

Secondly, if you are using Scrum for instance, the Scrum Master must work closely with the Product Owner/customer to ensure that the team is focused, daily, on the 875 story points.  This is what was initially determined by the customer to represent the 70% of features that will deliver the most value.  The 70% at this point becomes moot from a contract perspective because that will most surely change over the course of the effort.  Because the customer can add features and functions to the product backlog and because it is reprioritized and re-estimated continuously, 875 may not represent 70% of the backlog in the future.  This is acceptable in the sense that the contract is for 875 story points regardless of how the product backlog changes over time.  This contract is designed to deliver 875 story points.  No more.  If it is deemed by the Product Owner that more story points must be completed to represent value to the business then the contract needs to accommodate an increase in the number of sprints to be completed and ultimately an increase in the price.

Now here is the “fly in the ointment”.  Estimates will be changing throughout the project from sprint to sprint.  No matter how good you believe your initial estimates and uncertainty factors are you can’t have full confidence in them.  With enough accuracy erosion of your estimates over time your contracted 875 story points could potentially represent less of the features and functions than the customer originally expected.   So even though you hold the mark on delivering 875 story points it could represent less and less of what the customer expects you to deliver.

Sounds like you are right back where you started from right?  RIGHT!    Well folks, let’s face it.  That is the essence of the fixed price game.  And with agile, you cannot guarantee the scope.  You can definitely deliver high quality software in increments of time that you can commit to and increments of cost that you can commit to.  But you cannot commit that the scope will not change from what the original expectation may have been.   You are committing to delivering high quality software that the customer can feel, touch, and experience as it is being developed so that the resultant product is what they asked for.  You are committing to providing the highest level of velocity possible.  You are committing to accomplishing as many features and functions on the product backlog as humanly possible.  You are committing that you will not exceed the budget dollars that were set at the beginning of the project.  But you cannot commit to the percent of the product backlog that you will actually accomplish.

What am I saying here?  That you should not do fixed price agile projects.  Well, if you have a choice, probably not!  But we live in a world of budgets and deadlines that will ultimately require you to “fix” something.  So if you have to engage in a fixed price project, fix it on capacity (velocity) for a given period of time (e.g., 100 story points each sprint for 9 sprints) with a guarantee of the quality of each unit of software delivered.  However, since committing to a project model based on malleable scope is so foreign to the way in which most businesses have operated in the past, you are causing the customer some apprehension here.  You need to provide them with a lever of control.  Therefore, I (and others in the agile community) recommend that after each sprint, the customer can cancel the project if they do not feel that enough value will be attained by the end of the effort (you might want to add a small cancellation penalty to cover your ramp down costs).  If they get through 3 sprints and realize that only a fraction of the business value will be delivered before the budget is exhausted, they have only paid for 3 sprints and can seek other means of finishing the project if they choose or cancel it completely.

As I go back and review what I just wrote, I realize that this is not a perfect scenario.  But then again we have chosen a profession that does not fit neatly into a box.  Most of us in the software development business have been dealing with this and will continue to deal with this issue for the rest of our careers.  It all comes down to building trust with your customer community, taking it on the chin from time to time I suppose, and maintaining an open and honest channel of communication with your business customer.

I welcome your thoughts and insights.

Pete

Follow me on Twitter at www.twitter.com/peterdeyoe

Upcoming Webinar from ITMPI.org: Making Risk Based Testing a Reality

Hello All,

I have not posted  blog entries in a while.  I left my mind and my computer in the office and went away for vacation.  But now I am back and looking forward to getting back to our ongoing discussions.  This week I will be finishing a couple of articles that I hope will be of interest.  The first should be completed by tomorrow on the issue of Fixed Price contracts for Agile Development projects.

For now I wanted to make you all aware of a couple of events that you may be interested that ITMPI.org is sponsoring.

The first is a webinar that will be held on October 21, 2009 from 11:00 AM to 12:30 PM EST.  Here are the details:

Making Risk Based Testing a Reality

Presented By Fiona Charles

Risk-based testing focuses test efforts on the system areas where defects could do the most harm. But when risk assessment is done by the wrong people, the strategy fails. This webinar with Fiona Charles describes a process that has worked in many organizations for making risk-based testing a practical reality.

October 21, 2009 11:00am-12:30pm Eastern Time

You can register for this FREE Webinar at the ITMPI.org website.

The second is a seminar that will be held in Philadelphia, PA on October 20th on IT Risk Management.  See my earlier posting at http://peterdeyoe.wordpress.com/2009/09/24/it-risk-management-conference-in-philadelphia-keynote-dr-robert-charette/

I hope you can attend one or both of these valuable sessions.

Have a great day,

Pete

Follow me on Twitter at www.twitter.com/peterdeyoe

Another Great Webinar – Requirements by Collaboration: Defining Product Needs on Large Agile Projects

Hello All,

Another Great Webinar coming up for ITMPI.  Just saw this today.. Might be worth your while.  October 9th.

http://www.itmpi.org/webinars/

Enjoy the week.

Lipstick on a Pig…Last Call!

Hello All,

I sent this post out a week or so ago.  Still looking for some good stories on your experiences with implementing Agile.  Would love to hear from you.

http://peterdeyoe.wordpress.com/2009/09/23/lipstick-on-a-pig-calling-all-agile-practitioners/

Pete