Recent site activity

Agile Methods‎ > ‎

Agile Discussions

Recent Announcements

  • Fun at Workplace It is winter in Switzerland and we have a lot of time for talking because it is so cold outside. Quite a few of the discussions are about job opportunities ...
    Posted Feb 15, 2012, 2:24 AM by Marcel Baumann
  • Interesting Books I regularly recommend to Persons interested in Agile/Scrum Approaches Often I am told that it is difficult to use Agile/Scrum approaches for brown field projects or for big projects or for distributed projects or for any other situation ...
    Posted Feb 6, 2012, 12:48 PM by Marcel Baumann
  • Scrum Master Role I am very happy that more and more discussions are held what the role, responsibilities and activities of a Scrum Master is. The Scrum Master Manifesto is such an initiative ...
    Posted Oct 26, 2011, 6:33 AM by Marcel Baumann
  • Product Vision I always liked Roman Pichler a lot and send regularly collaborators and customers to his workshops and training. Below his input about product vision. The main activities are Probe and ...
    Posted Oct 26, 2011, 6:50 AM by Marcel Baumann
  • Minimum Criteria for Agile Introduction I often think that is necessary to transform a department or a company to become agile. The following are minimum criteria for being able to get full value out of ...
    Posted Oct 7, 2011, 2:29 AM by Marcel Baumann
Showing posts 1 - 5 of 15. View more »

Fun at Workplace

posted Feb 15, 2012, 2:21 AM by Marcel Baumann   [ updated Feb 15, 2012, 2:24 AM ]

It is winter in Switzerland and we have a lot of time for talking because it is so cold outside. Quite a few of the discussions are about job opportunities and how interesting and motivating the current activities are. I selected two articles to help everybody to decide if his software development job is worth the effort. Just go through the questions and ask yourself if the current project provides the current settings.
  • The Joel Test is slightly outdated. Keep his questions and just do the following changes
    • Can you replace CVS with Git to reflect the current state of the industry?
    • Move from daily builds to build at checkin. Remember "Daily Builds are for Wimps"
    • Do not only fix bugs but also write the associated automated tests. Remember "Defect Driven Development" to guaranty your customer he will never again see the same issue
    • Check that your specification also has acceptance criteria which can be automated
    • For Microsoft developers, are you forced to use TFS instead of tools of your choice and why?
    • Are you testers integrated in your Scrum team and sitting in the same room?
    • Do new candidates code and perform refactoring to achieve clean code during their interview?
  • 8 Questions to identify a lame programming job. The questions are up to date. His final remark is worth remembering
    • No matter how great the potential projects and teammates might be, I don't think you can do truly meaningful work in an environment where you, the developer, aren't empowered to succeed.  If a company doesn't get that, then they don't get software.
Take the ten minutes to decide if your current job is good enough. Otherwise if you living in Switzerland contact me :-)

Interesting Books I regularly recommend to Persons interested in Agile/Scrum Approaches

posted Feb 6, 2012, 12:43 PM by Marcel Baumann   [ updated Feb 6, 2012, 12:48 PM ]

Often I am told that it is difficult to use Agile/Scrum approaches for brown field projects or for big projects or for distributed projects or for any other situation or reason. Interestingly these persons also state that the same problem exist for RUP/OpenUP, Waterfall model DIN XT, Swiss variant called Hermes. Currently agile approaches are the standard for new projects and are thought in technical universities. Scrum is the main agile method and state of the industry approach for the realization of software projects.

To open the discussion and bring the discussion back to objective arguments I often recommend the following books
  • Big Projects and Distributed Projects
    • Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman and Bas Vodde, Addison-Wesley 2009
      This book and the one below are a very extensive presentation about the challenges and trade-offs of big distributed agile projects. Don't expect pre-cocked solutions but a tool set how to lead successfully such projects. Not always a easy reading but worth the effort
    • Practices fot Scaling Lean & Agile Development: Large, Multi-side, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, Addison-Wesley 2010
      See above for a review of the book
    • Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory, Addison-Wesley 2009
      The seminal reference book how to blend testing with agile projects. Lisa Crispin and Janet Gregory provides insights and a proven track how to guaranty agile quality assurance and agile testing. A must read book for everyone seriously developing agile projects
    • Agile Estimating and Planning, Mike Cohn, Prentice-Hall 2006
      The seminal reference about estimating agile projects. The experienced readers will understand why Mike Cohn used the words estimating and planning instead of estimates and plan.
    • The Enterprise and Scrum, Ken Schwaber, Microsoft Press 2007
      The work of one of the Scrum founders how a company can adopt Scrum. You should read the standard works of Scrum to understand the concepts.
    • Agile Project Management with Scrum, Ken Schwaber, Microsoft Press 2003
      The work of one of the Scrum founders how Scrum influence project organization and management. You should read the standard works of Scrum to understand the concepts.
  • Brown-Field Projects
    • Refactoring Improving the Design of Existing code, Martin Fowler, Addison-Wesley 1999
      How to implement continuous improvement on the code level. If you are not refactoring you are not agile.
    • Working Effectively with Legacy Code, Michael C. Feathers, Prentice-Hall 2005
      Most of us work on existing code bases. Based on the above statement you have to find a way to unit test and refactor legacy code if you want to be agile.
  • Extreme Programming
    • Test Driven Development by Example, Ken Beck, Addison-Wesley 2003
      How can a programmer be sure his code is working before and after refactoring
    • Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall 2009
      We are professional developers and uncle Bob shows how we should work
    • The Clean Coder: A Code of Conduct for Professional Programmers, Robert C. Martin, Prentice Hall 2011
      Uncle Bob define what a professional developer is. I know quite a few developers shocked by his requirements
  • Agile and Lean Concepts
    • Lean Software Development, An Agile Toolkit, Mary & Tom Poppendieck, Addison-Wesley 2003
      Classical work what lean development means
    • Implementing Lean Software Development: From Concept to Cash, Mary & Tom Poppendieck, Addison-Wesley 2007
      The hand-ons how to implement lean approaches
    • Agile Product Management with Scrum: Creating Products that Customers Love, Roman Pichler, Addison-Wesley 2010
      Requirement engineering done the agile way
    • Scrum and XP from the trenches: How we do Scrum, Henrik Knieberg, InfoQ 2007
      Short book how to implement Scrum and XP in projects
  • Change Management
    • Fearless Change: Patterns for Introducing New Ideas, Mary Lynn Manns & Linda Rising, Addison-Wesley 2005 
      The introduction of Scrum and agile principles means change in the organization and the teams. Linda Rising shows how changes are introduced with success in existing organizations.
  • Books everybody should have read
    • Peopleware: Productive Projects and Teams, Tom DeMarco & Timothy Lister, Dorset House 1987
      How to growth teams and lead successful projects
    • The Mythical Man-Month 2nd Edition, Frederick P. Brooks, Addison-Wesley 1995
      The first version was published in 1975. The rules postulated by Brooks are still actual. Sad is that a lot of project leaders have no clue of these rules.
    • Becoming a Technical Leader: An organic Problem-Solving Approach, Gerald M. Weingartner, Dorset House 1986
      How a gifted technical engineer can become a manager.
    • Slack: Getting past burnout, busywork, and the myth of total efficiency, Tom DeMarco, Broadway Books 2001
      In one sentence, the tremendous difference between efficiency and effectivity.
    • The Dilbert Principle, Scott Adams, Harper Collins 1996
      An entertainment presentation of all the mistakes companies are doing and still thinking they are smart
    • Death March: The complete Software Developer's Guide to Surviving "Mission Impossible" Projects, Prentice Hall 1997
      In my current coaching activities I still encounter departments where burnouts are common. Either these managers are criminals or so plain stupid that they cannot be held responsible. I am still unsure
I am curious about books you recommend for agile or other approaches. Just drop me an email.

Scrum Master Role

posted Oct 25, 2011, 4:26 AM by Marcel Baumann   [ updated Oct 26, 2011, 6:33 AM ]

I am very happy that more and more discussions are held what the role, responsibilities and activities of a Scrum Master is. The Scrum Master Manifesto is such an initiative. I agree with the Manifesto authors that Scrum Master role is a fulltime job when working with a new Scrum team and team members new to the Agile and Scrum way of working. But I am convinced that a Scrum Master can support multiple experienced Scrum teams. 

I worked with quite a few Scrum Master, Product Owners, and Scrum teams. I am convinced that it is more productive and effective that the Scrum Master works fulltime as coach and is not working on stories. It was very often a huge stress for Scrum Master being team member to prioritize their Scrum Master responsibilities against the commitment of the sprint goals. So I strongly recommend to have fulltime Scrum Masters.

More important is that you have real Scrum Masters, and not only Scrum administrators just organizing meetings and managing the backlogs, the Scrum board and the impediments list. I challenge you to read the Scrum Master Manifesto and check yourself. Do you live the 12 Scrum master pocket principles? Do you perform during each sprint the top 10 things a Scrum Master usually forgets to focus on?
  1. Redefining career paths and goals to be more scrum focussed
  2. Missing Product Backlog items
  3.  Team issues aren't being discussed because they are too uncomfortable
  4. Appropriate balance between end-to-end system test and unit tests
  5.  Playing back the team's progress against the proposed release plan
  6. All tests roll up into the continuous integration results
  7.  Team members realize the benefits of refactoring
  8.  Code is regularly peer reviewed
  9. Pair programming is being utilized
  10. Definition of done is being expanded
If you fulfill all the criteria of the manifesto please send me an email. I would like to work with you. If not the improvement measures should be clear.

I hope that the discussion what a successful Scrum master do stay active. It is a huge gain for the Agile community that people realize that a Scrum master is a coach, a line manager, and change catalyst.

Product Vision

posted Oct 12, 2011, 9:13 AM by Marcel Baumann   [ updated Oct 26, 2011, 6:50 AM ]

I always liked Roman Pichler a lot and send regularly collaborators and customers to his workshops and training. Below his input about product vision. The main activities are
  • Probe and Learn
  • Iterate
  • Do just enough
  • Visualize
I’ve named the tool that I use Product Vision Board. The board allows the product owner and the team to map out the key aspects of their product, and it helps the organisation decide if money should be spent on a new product. The product vision board describes seven aspects of a product: The target group, the needs addressed, the essential product features, its relationship to competitor products, the value it creates, its feasibility, and its product or user interface design. Additionally, it summarizes the vision in a one-sentence statement:

Project Vision Board

Minimum Criteria for Agile Introduction

posted Oct 7, 2011, 2:29 AM by Marcel Baumann

I often think that is necessary to transform a department or a company to become agile. The following are minimum criteria for being able to get full value out of an Agile environment:

  • Executive support: It may scare executives to imagine a company full of self-organizing groups in charge of the product development process, but Agile doesn't work unless those executives take the risk and respect rules around scrum team organization. 
    • Executives should understand that all development team members, including writers, would experience an adjustment period transitioning to Agile. No one expected a perfect transition. Managers communicated the need for patience across the organization.
  • Whole teams: Development, documentation, QA, and product management should be represented at all Agile meetings. Team members work the majority of their time together on the same project, team members stay in the team for at least until the release is delivered; a release has a duration of at least five sprints.
    • Scrum requests cross functional team so that all team members can work on any task on the Scrum board
  • Training and coaching: Organizations may latch on to a few elements of Agile methods, like just-in-time development or light organizational structure, but it really takes all the parts to make it work well. Your organization should invest in training and coaches to really make it work.
    • One main goal of Agile is continuous improvement to increase productivity and effectivity. Training and coaching are mandatory to improve the effectiveness of teams and individuals.
  • Tooling and effectivity: The team can order tools to improve their effectivity and reduce manual mundane tasks.
    • Working in an Agile environment is easier if all product development teams use the same tracking tool.
  • Occam Razor: If you use Scrum fulfill the few rules of the approach without exceptions. Do not tinker with the process, meetings, and artifacts. Feel free to use other approaches such Kanban or eXtreme Programming. But not call it Scrum.
    • Concept such as "getting to done" became clear after definitions with examples were provided. 

The good news is: you may still be able to use any of the following techniques to improve the documentation process in a not-entirely-Agile environment.

See also the wikipedia article about change management.

Impediments List is of tremendous importance

posted Oct 6, 2011, 5:51 AM by Marcel Baumann   [ updated Oct 6, 2011, 5:54 AM ]

A short self-test to verify that your Scrum approach is working in the area of the retrospective meeting and the impediments resolution.
  1. If the impediment backlog lives in the mysterious black book of the ScrumMaster, you have a problem
  2. If your impediment backlog does not change, you have a problem
  3. If your impediment backlog is empty, you have a problem
  4. If you have an impediment backlog with a growing number of active impediments, you have a problem
  5. If the ScrumMaster resolves all impediments himself, you have a problem
  6. If you do not solve at least one impediment each sprint, you have a problem
See the last publication at the Scrum alliance for a discussion of impediment resolution. As a Scrum coach, Scrum master or Scrum team member you should answer the above questions at least four times a year.

Scrum and fix priced contracts

posted Oct 5, 2011, 5:13 AM by Marcel Baumann

Often I am asked if it is possible to use Scrum approach in the context of fix price contracts. The answer is a sounding yes. Experience in projects show that you need to differentiate your definition of fix price contracts. Different customers have different needs. Below you find different contract models to guaranty customer satisfaction.

The approach is always the same. The requirements of the product are reformulated as user stories and each story is estimated. The unit of estimation is story points. The estimation is used to write down the fix price and the costs for each story and the associated requirements. During the realization the progress report and cost tracking is done against these stories. The release burn down chart shows the progress and the estimated release date.

   Classic Fix Price
 bbv Scrum Fix Price
 bbv Scrum Flexible Fix Price
 bbv Scrum Premium Fix Price
 Change Management
 No changes are possible without contractual renegotiation of costs and timelines through a change management board
 Exchange of non implemented stories always possible with new or modified stories
 Exchange of non implemented stories always possible with new or modified stories  Exchange of non implemented stories always possible with new or modified stories
Priority Management
 Not possible except as part of the initial fix price contract
At any time
 At any time
 At any time
 Controlling
  •  Not before completion of the project and the delivery of the release
  • Burn down chart for each sprint and each release
  • Burn down chart for each sprint
  • Potentially shippable product is delivered at the end of each sprint
  • Burn down chart for each sprint and each release
  • Potentially shippable product is delivered at the end of each sprint
  • Velocity and sprint report is delivered to provide forecast
  • Risk management of identified risks in implemented stories and new stories
  • Product release is provided at the completion of each release based on the release planning defined in the contract
 Early Completion of Project
 No  No  Yes, but no product release is delivered
 Yes, the last delivered product release is available for deployment on customer infrastructure
 Requirement Engineering
 Requirement engineering is performed by customer before definition of fix price contract
 Requirement engineering is performed by customer before definition of fix price contract  Requirement engineering is performed by customer, the Scrum team reviews the stories
 Requirement engineering is performed together with the customer to optimize ROI
 Constraints
  • Requirements are available at high quality and are frozen during the fix price
  • Requirement are available at high quality
  • Customer defines product manager for change management
  • Responsible attend review meeting at the end of each sprint and planning meeting at the beginning of each sprint
  • Requirement are available at high quality
  • Customer defines product manager for change management
  • Responsible attend review meeting at the end of each sprint and planning meeting at the beginning of each sprint
  • Installable software is available at anytime for feedback
  • Requirement are available at high quality
  • Customer defines product manager for change management
  • Responsible attend review meeting at the end of each sprint and planning meeting at the beginning of each sprint
  • Responsible grooms with the team the product backlog and defines the acceptance criteria
  • Installable software is available at anytime for feedback
  • Product release is delivered as scheduled and deployed on customer infrastructure

The above table shows how Scrum, and iterative incremental development can be realized in fix price contracts.

Estimation is easier if the requirement document of the customer provides the key use cases of the application to develop. The requirements are associated with the use cases before starting the estimation of each story and requirement.

The new Version of the Scrum Guide

posted Aug 2, 2011, 3:49 AM by Marcel Baumann   [ updated Aug 7, 2011, 1:10 AM ]

The new version of the Scrum Guide written by Ken Schwaber and Jeff Sutherland is available since July 2011. The older version was published in May 2009. I found quite interesting the precisions about the Scrum Master responsibility. I have often discussions with the customers and companies I coach about the responsibility of the Scrum Master.
  • Who is responsible for the introduction of the Scrum approach in the company? Often people state that the management should spread Scrum in the company. Ken and Jeff have a clear idea who is in charge of this.

    The Scrum Master serves the organization in several ways, including:
    • Leading and coaching the organization in its Scrum adoption;
    • Planning Scrum implementations within the organization;
    • Helping employees and stakeholders understand and enact Scrum and empirical product development;
    • Causing change that increases the productivity of the Scrum Team; and,
    • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

    So the Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He needs indeed senior management support but the Scrum Master daily job is to spread Scrum in the company.

  • Who should coach the product owner to write better backlog and clarify the vision?

    The Scrum Master serves the Product Owner in several ways, including:
    • Finding techniques for effective Product Backlog management;
    • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
    • Teaching the Development Team to create clear and concise Product Backlog items;
    • Understanding long-term product planning in an empirical environment;
    • Understanding and practicing agility; and,
    • Facilitating Scrum events as requested or needed.

    So the Scrum Master should also coach the product owner and support him in the long term planning, the communication of the vision and backlog management. The vision and goals of the project should always contain an overall planning frame. During the project empirical evidence will trigger revision of the milestones and product planning.

  • What is the meaning of done and a piece of potentially shippable product?

    When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of “Done”” for the Scrum Team and is used to assess when work is complete on the product Increment.

    Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

    As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.

    The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be ““Done””, which means it must be in useable condition and meet the Scrum Team’s Definition of “Done”.

    It must be in useable condition regardless of whether the Product Owner decides to actually release it.

    So at the end of sprint all stories realized since the start of the project must be correct. Therefore you need automated acceptance tests to guaranty their correctness. The Scrum team must guaranty that at the end of each sprint all functions of the product work as specified and accepted by the product owner in the current and previous sprint reviews.

    Higher quality is reached through extreme programming approach: test driven development, clean code, pair programming, pair check-in, coding dojo, static analysis tools.

  • Does Scrum consider long-term planning?

    Yes it is a major activity performed by the Scrum Master and Product Owner. See the above point about the Scrum Master coaching the Product Owner. See if anyone states that long-term planning is not part of the Scrum theory you should challenge them and give them the Scrum Guide to read.

  • What can be changed during a Sprint? Often customers have heated discussions what can be changed during a sprint. Here a clear statement.

    During the Sprint:
    • No changes are made that would affect the Sprint Goal;
    • Development Team composition and quality goals remain constant; and,
    • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

  • What is measured in a burn down chart?

    Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

    The only relevant information is the amount of work still open and when this work will be completed. This is true for sprint, release and whole backlog burn-down chart.
I am glad that these precisions were added to the new version of the Scrum guide. I simplify my daily work. I can now simply refer the official Scrum Guide to convince people how aspects of Scrum should be understood.
The older version of the Scrum Guide is still relevant because it contains hints and best practices no more part of the new version.

Agility, Scrum and the marketing departments

posted Jul 20, 2011, 6:12 AM by Marcel Baumann   [ updated Jul 20, 2011, 6:23 AM ]

I always wondered how serious the Microsoft marketing people are about Scrum and agile approaches. Do they embrace the agile Manifesto or just want to sell more TFS - Team Foundation Server - licenses. One father of Scrum, Ken Schwaber has similar doubts. Read his post about Microsoft and Scrum. He expresses the same critics as we do when talking about empowered teams, self-organization and communication to the management. If you are using established project management approaches such as PMI see also Agility and PMI.

Another interesting new is that the Scrum guide - the small document with a blue cover - will be updated in the next days and reflect the changes they defined the last two years.

Stay tuned for a discussion about the guide as soon as posted.

Minimizing Undone Work when Working with Regulatory Departments

posted May 31, 2011, 2:32 AM by Marcel Baumann

The Scrum and agile mantra is to have a "ready to ship" product each time a sprint is completed. You must avoid any uncomplete activities at any price. Uncomplete activities are also called Undone Work; they are technical debts in your software, hindrering its delivery to customers.
 
Regulatory and traditional quality insurance departments requests all kinds of documents such as review, test results, risk analysis matrix to insure that their view of quality is fulfilled.
 
Scrum sees quality similar to the lean production approach. Quality is build into the product and you do not need any documents proving you have fullfilled this goal. Your sole goal is to optimize the process to produce best products, not to repair them after production. And it is the sole responsibility of the Scrum team to guaranty quality. But Scrum teams also learnt you cannot win against big corporations. So you have to divise solutions satisfying the QA departments with minimal overhead and almost no undone work. We have experience working with quality insurance and TUV or FDA driven regulatory departments. We use the following approaches to handle the needs of the regulatory departments, seen as stakeholders in the Scrum terminology.
  • Use static analysis tools such as PMD, Checkstyle, Findbugs to create quality gate reports for your QA department. Thousands of checks and hundred of pages of reports will satisfy any QA department. Plugins exists for Eclipse and continuous integration servers.
  • Use review plugin such as Eclipse Jupiter to create these still mandatory review reports on the source code. These reports are useless in an agile team working with techniques such as refactoring and pair programming. But they are still mandatory for the majority of traditional QA departments. The plugin allows you the generate nice looking reports and to implement the findings at the same time.
  • Use Test Driven Develpment approach and create a lot of unit tests. By slightly extending the logging features of JUnit and by using code coverage tools you can create reports showing which source code was tested. Add some annotations to your test cases and you have full traceability to your stories and associated software requirements. With a small amount of work you can generate thousands of pages of information and provide the PDF documents to the regulatory department. These documents are also TUV and FDA compliant.
  • Use Behavior Driven Develpment approach and create acceptance criteria for all your stories. Using the reporting features of easyb you can create acceptance test reports for all your stories and generates hundreds of pages of information and provide the PDF documents to the regulatory department. These documents are also TUV and FDA compliant
  • Use continuous integration servers to run all the above measures and generate the documentation at the end of each sprint or release.
  • Link you version control system with your continuous server, issue tracking system and unit tests. So you can generate release notes stating the list of closed issues with the associated source code and unit tests verifying the correctness of the change.
Similar tools are available in the .NET and C++ community. Therefore you can easily satisfy your QA and regulatory stakeholders with a lot of reports nobody will ever read. A real Scrum team corrects weaknesses during the development process and always deliver a software of highest quality. Therefore the reports can only show the inherant quality of the software and are not worth the paper they are printed on. But you satisfy powerful stakeholder groups and can more freely work on the most important goal. Deliver on time and in budget the best software the customer wants to have.

1-10 of 15

Comments