Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

Why Are Requirements So Hard To Get Right? (part 2)

0322141511a

Not the most efficient communication technique

IT projects have been around in one form or another since the 1940’s. Looking back in the literature describing the history of IT, the topic of requirements in general and identification of requirements specifically have been top of mind since day one.  There are numerous definitions of ‘requirements,’ however at a high level requirements can be thought of as what the functionality developed by the project should ‘do’. Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.  This confluence forms a set of three constraints that are overlaid on flowing time which ensures subtle changes are continually being introduced to all of the variables.  A breakdown of process, people or environment will reduce the effectiveness of the result or render it unusable.  The factors driving the people category are typically the most volatile and a seemingly least controllable of all of the variables within the requirements process.  This essay will focus on the ‘people’ category with subsequent essays focusing on process, environment and suggestions for solutions.

People have a major impact on the vagaries of requirements.  All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product. A few of the more intractable contributors to requirements variance are:

  1. Lack of experience
  2. Human nature
  3. Communication
  4. Organizational politics

This is the continuation of our discussion in which we address communication and organizational politics.

Communications problems can be secondary effects of other initiating events such as a software defect, a missed date or a dropped requirement. The communication component of dealing with the problem compounds the problem.  The problem is compounded by the fact that many people just don’t communicate well because:

  • They don’t listen because they think they already to know the answer,
  • There are those that do not know enough about the business therefore can not interpret what they hear,
  • There are interviewees that don’t choose to answer the question asked,
  • or Interviewers that don’t ask the right question, and
  • Or interviewees that are the wrong person to interview.

The list could go on further; there are just lots of things that can go wrong.  Communication is a combination of getting the right people with the right knowledge facilitated correctly all in the right place at the right time.

Organization politics can cause communication problems by creating filters between the speaker and listener.  One example of a problematic type of organization politics is a topic called solution-driven requirements (also called a solution searching for a reason or an answer searching for a question). In teams or groups that organize around specific technical solutions (vendor packages) for example tend to look for ways to apply their solution to increase or maintain their organizational base. Unfortunately humans are great at recognizing patterns, and a solution is a pattern.  Pattern recognition is a survival technique however it has drawbacks for gathering requirements.  Gathering requirements with the solution already in mind is  like a solution hunting for a problem. Anything that potentially blocks the ability for interviewees to express themselves freely or for interviewers to hear business needs can potentially create a scenario where errors or omissions occur. Remember when all you have is a hammer you’re apt to see everything as a nail rather to consider that you might need some other tool.

There are a number of tactical solutions for all of these issues, however the first step to solving requirements issues that are people-centric begins with recognizing that a problem exists.  One best practice that I would recommend, taking a page out of the Agile handbook, is to use coaches to support the people working on gathering and managing requirements.  The role of coaches is to be the voice of the people focused inward on the team and the work.  A coach observes how work is done, provides support and instruction in a consistent and focused manner when and where it is needed.  This role is different from that of project manager which is externally focused, interacting with outside parties and clearing external roadblocks.  While people are not the only factor driving the quality of requirements, they are a critical factor.  Pay attention to how people are being deployed, provide support and instruction and make darn sure the right people are in the right place at the right time.


Categories: Process Management

Done & Retrospectives in Scrum, Software Architecture in Methods & Tools Spring 2014 issue

From the Editor of Methods & Tools - Mon, 03/24/2014 - 16:05
Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Spring 2014 issue that discusses how to be bone in Scrum; why, when and how to perform successful retrospectives; Why it is better to chop onions instead of layers for a improved software architecture. Methods & Tools Spring 2014 contains the following articles: * The Principles of Done * Doing Valuable Agile Retrospectives * Chop Onions Instead of Layers in Software Architecture * Ranorex – Automated Testing Tool for Desktop, Web & Mobile Applications 40 pages of ...

SPaMCAST 282 – Ben Linders and Luis Gonçalves on Retrospectives

Software Process and Measurement Cast - Mon, 03/24/2014 - 03:00

Listen to the Software Process and Measurement Cast 282. In the SPaMCAST 282 we feature our interview with Ben Linders and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all projects and organizations need to deliver more value over time.

Luis Gonçalves is an Agile Coach, Co-Author, Speaker and a Blogger. He has been working in the software industry since 2003, being an Agile practitioner since 2007. Luis is the co-author of “Getting Value Out of Agile Retrospectives” and a co-founder of a MeetUp group in Munich called High Performing Teams.

He likes to write and share ideas with the world and this made him passionate blogger. You can follow his blog: http://lmsgoncalves.com. People can find Luis on twitter: @lgoncalves1979

Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. Co-author of Getting Value out of Agile Retrospectives. As an advisor, coach and trainer he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English) and as an editor for Agile at InfoQ. You can find him on twitter: @BenLinders.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on user stories.  A user story is a brief, simple requirement statement from the user perspective. User stories are narratives describing who is interacting with the application; how they are interacting with the application and the benefit they derive from that interaction.

Upcoming Events

ISMA 9

I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.

More information

QAIQuest 2014

I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team." Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

SPaMCAST 282 – Ben Linders and Luis Gonçalves on Retrospectives

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 282. In the SPaMCAST 282 we feature our interview with Ben Linders and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all projects and organizations need to deliver more value over time.

Luis Gonçalves is an Agile Coach, Co-Author, Speaker and a Blogger. He has been working in the software industry since 2003, being an Agile practitioner since 2007. Luis is the co-author of “Getting Value Out of Agile Retrospectives” and a co-founder of a MeetUp group in Munich called High Performing Teams.

He likes to write and share ideas with the world and this made him passionate blogger. You can follow his blog: http://lmsgoncalves.com. People can find Luis on twitter: @lgoncalves1979

Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. Co-author of Getting Value out of Agile Retrospectives. As an advisor, coach and trainer he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English) and as an editor for Agile at InfoQ. You can find him on twitter: @BenLinders.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on user stories.  A user story is a brief, simple requirement statement from the user perspective. User stories are narratives describing who is interacting with the application; how they are interacting with the application and the benefit they derive from that interaction.

Upcoming Events

ISMA 9

I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.

More information

QAIQuest 2014

I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

Why Are Requirements So Hard To Get Right?

photo (14)IT projects have been around in one form or another since the 1940’s. Looking back in the literature describing the history of IT, the topic of requirements in general and identification of requirements specifically have been top of mind since day one.  There are numerous definitions of ‘requirements,’ however at a high level requirements can be thought of as what the functionality developed by the project should ‘do’. Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.  This confluence forms a set of three constraints that are overlaid on flowing time which ensures subtle changes are continually being introduced to all of the variables.  A breakdown of process, people or environment will reduce the effectiveness of the result or render it unusable.  The factors driving the people category are typically the most volatile and a seemingly least controllable of all of the variables within the requirements process.  This essay will focus on the ‘people’ category with subsequent essays focusing on process, environment and suggestions for solutions

People have a major impact on the vagaries of requirements.  All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product. A few of the more intractable contributors to requirements variance are:

  1. Lack of experience
  2. Human nature
  3. Communication
  4. Organizational politics

We’ll discuss the first two today and deal with points 3 and 4 on Monday.

Two types of experience are the most germane to this discussion.  The first is whether participants have knowledge of the problem space from a business perspective. Without that the requirements may not practically address the project needs. Knowledge of and experience in the problem space is critical for effectiveness. One technique that has been developed to mitigate this risk is to ensure access to business knowledge through co-location with a business partner.  This kind of access is a central tenet of the most of the Agile methods. The second category is experience with the requirements process itself. Without experience gathering, recording and managing the requirements process, it will be difficult to ensure information gathered is correct and that the results developed will be apt to be more costly than necessary and less valuable than needed.  Agile methods use coaching to reinforce this knowledge and experience, while other methods use training and processes.  The goal is the same in both cases: efficiency and effectiveness.

Human nature can act as tool to focus or redirect the requirement process.  Watching several requirements gathering systems has lead me to the conclusion that there is a natural tendency for groups to jump to defining the solution before defining the need.  This can lead to a number of communication issues.  Needs provide a locus for grounding the work, which focuses the solution.  It is important to remember in the grand scheme of life needs change before the solution changes, rather than the solution changing the need (even though in exceptional cases this can be true).

There are a number of tactical solutions for all of these issues, however the first step to solving requirements issues that are people-centric begins with recognizing that a problem exists.  One best practice that I would recommend, taking a page out of the Agile handbook, is to use coaches to support the people working on gathering and managing requirements.  The role of coaches is to be the voice of the people focused inward on the team and the work.  A coach observes how work is done, provides support and instruction in a consistent and focused manner when and where it is needed.  This role is different from that of project manager which is externally focused, interacting with outside parties and clearing external roadblocks.  While people are not the only factor driving the quality of requirements, they are a critical factor.  Pay attention to how people are being deployed, provide support and instruction and make darn sure the right people are in the right place at the right time.


Categories: Process Management

Safe to Fail Experiments Are About Learning

Safe to fail experiments are about education.

Safe to fail experiments are about learning

In IT, ‘safe to fail’ describes activities that are used to generate knowledge. Additional terms that might be used are probes, spikes, R&D and prototypes. The outcome of a safe to fail experiment can be innovation, the information necessary to make decisions or to discover alternatives.  All these scenarios are appropriate for a safe to fail experiment however regardless of intent sometimes safe to fail  experiment are not safe nor are they appropriate.

Safe to fail experiments are appropriate in situations where learning is required to deliver a project. An experiment or a bit of prototyping might be needed to learn whether something is possible or if there is a more effective way to perform a repetitive task. For example, earlier in my career my team converted credit card portfolios from one provider to another. We used a standard process for most of the hard work. We were always looking for a way to make the process more efficient  using mock conversions as experiments. The goal was to find better processes and techniques.  These experiments did not always yield process changes, but they always added to our knowledge of what would and wouldn’t work. Another opportunity for safe to fail experiments is in situations where several possible alternatives exist. You need an experiment to determine which (if any) of the alternatives make sense. A test or an experiment is considered successful if it proves either that an alternative is a good choice OR if the results can be used to cross an alternative off the list. Organizations that judge results that can disqualify an alternative as a failure are apt sort out alternatives in the market place rather than before they go into production because experiments will not be safe. Finally, safe to fail experiments are useful tools in formal decision-making frameworks. For example, frameworks built to comply with the CMMI process area, Decision Analysis and Resolution (DAR), often leverage safe to fail experiments to generate data for formal, structured decision-making.

Safe to fail experiments are not always appropriate.  Many projects exist with a both fairly well understood solution and a hard deadline. In some portion of these projects the solution may not be perfectly optimal or the coolest possible solution, but it is doable in the timeframe. Experimenting to find a more optimal solution when taking the time and effort could cause you to miss the due date is not appropriate. In the credit card example mentioned earlier, we explored new ideas and optimization between projects to avoid experiments that would put the conversion at risk or cause the team to miss more of their weekend than was already necessary. Experiments that imperil the commitments a team has made or inhibits their ability to effectively deliver are not experiments and are safe to fail. Experimenting is also not appropriate where negative results are thought of as a black mark on a career. In this case straying from the tried and true approaches are generally a bad idea. This scenario tends to occur in highly politicized or overly competitive organizations. In this type of scenario if you can’t change the environment, I would suggest experimenting with other job opportunities. A third scenario is more questionable than absolutely inappropriate. In scenarios where there is little potential upside to the experiment experimentation is probably not a good idea. In most organizations, time and attention are always in short supply. Every team needs to judge what it needs to learn and ration resources that are in short supply when there is little or no perceived upside.

Safe to fail experiments are scenarios where an organization or team truly wants to sift through possible alternatives before using them in a project or in production. Safe to fail experimentation is an application of the scientific method (testing hypotheses) to generate knowledge and decisions so that teams and projects deliver more value.


Categories: Process Management

Teams Have Peak Load

photo1Peak load is an engineering concept that has found its way into software development and maintenance conversation.  In electrical engineering, it is a measure of the maximum electrical demand a system will make on the electrical grid. Software testers apply a version of this concept in stress and load testing scenarios. Peak load is by definition a spike over a specific period of time and not a sustainable level of performance. When applied to a software team, the peak load is how much additional work a team can do for a short period of time. While the principles in Agile Manifesto call for a sustainable pace, all teams know that they can call on a reserve of energy for a brief period of time to accomplish a specific goal.

In classic plan-based projects, we have all observed teams expending huge amounts of energy just prior to the overall due date or implementation. Similar patterns of behavior can sometimes be seen on sprint teams when the team is rushing to complete their committed stories as the last day of the sprint approaches.

In a normal Agile team, the average velocity (the average number story points or function points completed) is a good proxy for a stainable pace. I generally suggest that a team can occasionally increase its velocity by approximately 10 – 20% for a single sprint. For example, a team that averaged 20 function or story points might be able to commit to deliver 22 – 24 points as their peak load. In some more extreme spikes, there are frequently stories that are not completed or have quality problems.  However, this all assumes that the average velocity is really the team’s norm, rather than something they have achieved while being whipped. The problem with a team working at peak load is that sooner or later the team will have to revert to the mean, which means that it will look like the team is underperforming. If the team’s performance is graphed you will see a classic saw tooth pattern. The lack of consistency can hurt the team’s ability to deliver by first exhausting the team and them creating a scenario where they publicly underperform.

In electrical systems pushing a machine or appliance to peak load stresses the system and generates wear and tear. In the long run, this leads to breakdowns and the need for repairs. Teams are no different.  The big difference is that, given a compelling goal and then time to recover, teams can rise to a higher of performance, to a peak load, for a short period of time without have to be put in the shop for repair. The idea of pushing a team to a peak load should be used judiciously.


Categories: Process Management

Who is Responsible? You Are!

He's looking at you...

He’s looking at you…

Who is responsible for results on a sprint team? I was once asked “whose throat I should step on when the project is in trouble?” In a classic project, the answer would be the project manager (or a similar position). In an Agile project that is living up to the principles espoused in the Agile Manifesto, the answer is a bit messier and that messiness makes a command and control leader very nervous.

Agile projects using Scrum as their organization and management framework have three basic roles: product owner, scrum master and team.  If we were looking for a throat, which one would we select? The product owner owns the backlog, the budget, is charge of prioritizing the work and provides leadership. The scrum master coaches, teaches and generally facilitates the team while removing barriers to performance and provides leadership. The whole team plans the work, tackles issues and swarms to problems and individuals provide leadership when necessary. Agile teams are self-organizing and to an extent self-managing (the organization generally decides on which projects get done based on strategic plans). The whole team is involved in planning the work and, at least at situational level, everyone on the team can provide leadership. If you were to ask the members of an Agile team to point at who is in responsible, you might not have many people pointing in the same direction. Therefore is the answer that no one is responsible?

Everyone on the team is in charge.  Everyone on the team is accountable for meeting the goals that the organization sets out as interpreted by the product owner (through the backlog) and accepted by the team.  The planning activities of public acceptance and commitment to the goals and stories of the sprint creates a pressure to do what has been committed. Demonstrations act as the bookend to the public commitment with the team publicly showing how they performed against the goals they committed to attaining. If we assume that the team is empowered to attain the goals they have committed to attaining, then the team truly is responsible as a whole.

Answering that the team is responsible sounds way too squishy for some organizations. In the end, whoever controls the budget is the person that should be accountable. This suggests that the product owner should be responsible or IT management if the budget is allocated as overhead. Neither of these scenarios is conducive to empowering a self-organizing team.

Who is in charge of a typical sprint team? Every person on the team is responsible for holding each other accountable for meeting their goals. The product owner and scrum master have a direct hand in setting and facilitating the goal, therefore everyone on the team is both accountable and responsible. The layers of interlocking responsibility produce significant peer pressure. That means that every team member can truthfully say that they ARE responsible for the project.


Categories: Process Management

Function Points Are Still Relevant

Untitled

Are function points relevant in 2014? In this case, the question is whether function points are relevant to the size of an application, a development or an enhancement project. IFPUG Function Points were proposed in 1979 by Allan J. Albrecht, published in 1983 by Albrecht and Gaffney while at IBM and then updated and extended over the years. Just like using a tape measure to determine the size of the room, function points are a tool to determine the size of the application or project. In order to determine relevance we need to answer two questions:

  1. Do we still need to know “size”?
  2. Is knowing size sufficient to tell us what we need to know?

Size as a measure has many uses, but the two most often cited are as a component in parametric estimation and as a denominator in metrics such as time-to-market and productivity. While there still might be an intellectual debate on the effectiveness of estimation, there has been no reduction in the sponsors, executives, purchasing agents and the like requesting a price or an end date that you will be held accountable to meet.  Until those questions cease, estimation will be required. Parametric estimation processes (the second most popular form of estimation, after making up a number) require an estimate of size as one of the inputs.  Parametric estimation helps to avoid a number of the most common cognitive biases exhibited by IT estimators (e.g. optimism and assumption of knowledge).

Size is also used as a normalizing factor (a denominator) to compare effort (productivity), duration (time-to-market) and defects (quality). This type of quantitative analysis is used to answer questions like:

  • Is our performance improving?
  • Are the techniques being used delivering value faster?
  • Are we staffed appropriately?

Function points deliver a consistent measure of functional size based on a consistent set of rules.

The second and perhaps more critical question is whether the balance between functional requirements (things users do) and non-functional requirements (things like usability and maintainability) have changed when implemented in the current environment. If the balance has changed then perhaps measuring functional size is not relevant or perhaps not sufficient for estimation or productivity analysis.  A literature search provides no quantitative studies on whether the relationship between functional and non-functional requirements (NFRs) has changed.  Anecdotally, the new architectures, such as heavily distributed systems and software as a service, have caused an increase in the number and complexity of NFRs. However there is no credible academic evidence that a change has occurred.

It should be noted that some measurement organizations like the IFPUG have developed and begun evolving measures of non-functional size.  IFPUG has released the(SNAP) version 2.1, which measures the size of NFRs. These measures are still in the process of being incorporated into software estimation tools and are considered an augmentation to functional size measures like IFPUG Function Points or COSMIC (another form of function points).

Function points are still relevant because organizations, sponsors and purchasing agent still want to know how much a project will cost and what they will get for their money.  Organizations still want to benchmark their performance internally and externally.  Answering these kinds of questions require a standard measure of size. Until those questions stop being important, function points will be relevant.

FYI: Many times the question of relevance is really code for: “Do I have to spend my time counting function points?”  We will tackle that issue at a later date, however until then if effort is the real issue, call me and let’s discuss Quick and Early Function Points.


Categories: Process Management

NoSQL Databases Adoption Survey Results

From the Editor of Methods & Tools - Tue, 03/18/2014 - 14:20
NoSQL databases (MongoDB, Couchbase, Riak, Cassandra, etc…) are getting more and more visibility in software development discussions and conferences. The last Methods & Tools survey wanted to know if organizations were using NoSQL databases. The results are mixed. On one side, 60% of the participants answered that their organization was not using at all this technology, with 20% that are even unaware of their existence. On the other side, more than 25% of the organizations had NoSQL-based applications in production, which is not so bad for a relatively new technology largely ...

Know Exactly What Velocity Means to Your Scrum Team

Mike Cohn's Blog - Tue, 03/18/2014 - 13:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

When talking about it informally, I define velocity as simply a measure of how fast a team is going. And for most purposes, this definition works quite well. However, it creates confusion on some of the finer points of what should count in calculating a team's velocity. This confusion comes about because there are really two more precise ways of defining velocity. Let's see what they are.

1) Velocity measures how much functionality a team delivers in a sprint.
2) Velocity measures a team's ability to turns ideas into new functionality in a sprint.

Those may sound the same. They are subtly different. To see how, suppose you hop in a river and begin swimming. After an hour, you measure how far you've traveled, and you are 2 kilometers from where you began. In agile terms, we might want to call this your velocity and say you swim 2 kilometers per hour or per sprint, if a swimming sprint is an hour long.

But, what if the river had been flowing at the rate of one kilometer per hour against you while you swam? In that case, you really swam 3 kilometers. Measured against the banks of the river, you've only moved two kilometers of physical distance. But while going forward two kilometers, you overcame being pushed backward one kilometer by the river.

So, is your velocity two or three? If we use our first definition—velocity is how much a team delivers in a sprint—then velocity is two. This swimmer delivered 2 kilometers of progress.

If we use our second definition—velocity is the ability to turn ideas into new functionality—then velocity is three. This swimmer has the ability to deliver 3 kilometers of progress per sprint, and we'd see that he was swimming in a lake with no current instead of a river.

To see how this applies to an agile project, consider the issue of whether a team should earn velocity credit for fixing bugs during a sprint. A team that uses velocity to measure how much functionality is delivered in a sprint will not claim credit for bug fixes. No new functionality has been delivered. So no points are earned.

A team using defining velocity as the ability to turn ideas into functionality, on the other hand, will claim credit for bug fixes. Their logic is that the time spent on bug fixing could have been spend adding new functionality except the product owner prioritized different work for them.

For many teams, the two definitions will yield the same value. Values will differ most for teams doing work for which they are not taking velocity credit--usually teams doing things like a lot of bug fixing or doing large amounts of refactoring.

Neither of these subtle differences in the definition of velocity is always better than the other. The one you use should largely depend on what you hope to learn by measuring it and by your expectations about the future.

If you expect the future to be just like today—that is, the team will spend the same amount of time doing bug fixing, refactoring and the like as they do now, then using velocity as a measure of how much forward progress is made will be the right answer for you.

However, if you expect the future to be different—perhaps the large refactoring and time spent fixing bugs will soon be over—then you may want to define velocity as the team's ability to turn ideas into functionality, and would then add to velocity the points given to those activities.

The most important thing is to clarify with everyone on the team, including the product owner and ScrumMaster, is exactly what your team means when they use the term “velocity.” Having a precise definition makes it very easy to answer questions that come up around what should be counted when measuring velocity.

Agile Can Contribute to an Acceleration Trap

Accelerating when you a plotting a change in direction can be a problem.

Accelerating when you a plotting a change in direction can be a problem.

I am often asked whether Agile techniques contribute to an acceleration trap in IT.  The Harvard Business Review (April 2010, Bruch and Menges,  http://hbr.org/2010/04/the-acceleration-trap/ar/pr) defines an acceleration trap as the malaise that sets in as an organization fails prey to chronic overloading. It is interpreted as laziness or recalcitrance, which then elicits even more pressure to perform generating an even deeper malaise. The results of the pressure/malaise cycle are generally a poor working atmosphere and employee loss. Agile is often perceived to induce an acceleration trap in two manners: organizational change and delivery cadence.

Implementing Agile requires substantial and sustained organizational change. Implementing Agile generally affects team structure, the work and process management and technical techniques impacting configuration management, testing and coding. Changes of these types are almost never deployed in a single big bang, but rather in waves with minor tweaks being made in-between changes based on feedback. All organizations have a different “carrying weight” when it comes to change, or the amount of change an organization can absorb before the level resistance overcomes the pressure to change. Many factors can influence the carrying weight an organization can internalize, and therefore avoid an acceleration trap.  Factors include including organizational change management programs (selling the change), level of involvement and the pressure to change.  The first two items on the list should be built into the change program. Organizational change management programs generally help make the case for change, layout the benefits of change and seek buy-in. Getting the people who are being asked to change involved in planning and implementing the change helps to combat feelings of victimization that can occur. The third category, the pressure to change, is generally a reflection of market performance. I have often observed that a good “near death experience” (organizationally speaking) significantly increases the ability of an organization to change. Change driven by desperation is not something anyone wants to live through and you are asking for trouble if you try to fake it.

The principles of the Agile Manifesto call for a sustainable pace of delivery. The pace should be set to be able to be maintained indefinitely. Organizations that use Agile to address projects with a fixed scope and set delivery dates will generally find early success as Agile accelerates early delivery of functionality.  This initial success is often followed by burn out as team cannot maintain the pace of delivery. A common pattern I have observed is that a team is able to increase its velocity for a few sprints until suddenly it encounters a sprint in which nothing seems to go correctly and average velocity is negatively impacted.  This saw tooth pattern can either be reflection of exhaustion or overstepping. Both are a sign of an acceleration trap.  A simple solution (or maybe an overly simplistic solution) is not to agree to fixed scope and fixed deadline projects. A less simple solution would include integrating the development of a minimum viable product (MVP) into all release plans for all relevant projects, so that unsustainable cadences can be avoided. The introduction of an MVP into the concept of a backlog and release plans will require educating both the Agile team including product owner and other IT stakeholders.

Agile can add to the possibility of an acceleration trap if change management is not addressed or the change to Agile is imposed on project teams. Further accepting unrealistic projects, Agile or not, can lead to all sorts of problems, including an acceleration trap. Neither of these categories of problems HAVE to create an acceleration trap, if action is taken early.  Failure to address the causes of the acceleration trap is more to blame than Agile.


Categories: Process Management

SPaMCAST 281 – Value Chain Mapping, Kim Pries The Software Sensei on Big Data

Listen to the Software Process and Measurement Cast at www.spamcast.net

Listen to the Software Process and Measurement Cast at http://www.spamcast.net

Listen to the Software Process and Measurement Cast 281. SPaMCAST 281 features our essay on value chain mapping. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. Driving effective change requires an understanding of your organization’s value chain.

Value chain mapping is a representation of how an organization transforms raw materials into a product and then delivers that product to its customers.  Value chains are developed so that the organization can get a full understanding of the process to see how they can generate the greatest possible value for the organization and the customer.  Once you understand the flow, it is far easier to improve it. Value Chain Mapping is a lean technique. Like Kanban, which focuses on the flow of work and which steps add business value, Value Chain Mapping helps to target process improvements.

Listen to the rest on SPaMCAST 281.

The SPaMCAST 281 also features Kim Pries’s column. The listeners have spoken and Kim’s column now has a name: The Software Sensie. In this edition, Kim tackles big data in his illuminating and technical style.

Here are the related value chain mapping blog entries:

Value Chain Mapping
Value Chain Mapping: Value Chain or Process Map?
Value Chain Mapping: Components
Value Chain Mapping: A Simplified Process
Value Chain Mapping: Troubleshooting
Value Chain Mapping: Creative Tension

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our interview with Ben Linders (this is Ben’s second appearance on the podcast) and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all project and organizations need to deliver more value over time.

Upcoming Events

Agile Philly March Meeting:

I am speaking at Agile Philly’s March 18th meeting on the topic of Function Points. The meeting begins at 630 PM EST – 830 in King of Prussia, PA – Details at http://www.agilephilly.com/events/function-points

ISMA 9
I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.
More information

QAIQuest 2014
I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast
I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.


Categories: Process Management

SPaMCAST 281 – Value Chain Mapping, Kim Pries The Software Sensei on Big Data

Software Process and Measurement Cast - Sun, 03/16/2014 - 22:00

Listen to the Software Process and Measurement Cast 281. SPaMCAST 281 features our essay on value chain mapping. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. Driving effective change requires an understanding of your organization’s value chain.

Value chain mapping is a representation of how an organization transforms raw materials into a product and then delivers that product to its customers.  Value chains are developed so that the organization can get a full understanding of the process to see how they can generate the greatest possible value for the organization and the customer.  Once you understand the flow, it is far easier to improve it. Value Chain Mapping is a lean technique. Like Kanban, which focuses on the flow of work and which steps add business value, Value Chain Mapping helps to target process improvements.

Listen to the rest on SPaMCAST 281.

The SPaMCAST 281 also features Kim Pries’s column. The listeners have spoken and Kim’s column now has a name: The Software Sensie. In this edition, Kim tackles big data in his illuminating and technical style.

Here are the related value chain mapping blog entries:

Value Chain Mapping
Value Chain Mapping: Value Chain or Process Map?
Value Chain Mapping: Components
Value Chain Mapping: A Simplified Process
Value Chain Mapping: Troubleshooting
Value Chain Mapping: Creative Tension

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our interview with Ben Linders (this is Ben’s second appearance on the podcast) and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all project and organizations need to deliver more value over time.

Upcoming Events

Agile Philly March Meeting:

I am speaking at Agile Philly’s March 18th meeting on the topic of Function Points. The meeting begins at 630 PM EST – 830 in King of Prussia, PA – Details at http://www.agilephilly.com/events/function-points

ISMA 9
I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.
More information

QAIQuest 2014
I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast
I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team." Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

It Takes A Team

It Takes A Team

It Takes A Team

Hand Drawn Chart Saturday

An Agile team is comprised of a product owner, team members (all disciplines needed to deliver the project) and the scrum master. Delivering on the team’s commitment is the ultimate measure of value. The scrum master helps to create an environment for the team to work together. Over the life of a project, everyone on the team has to lead and facilitate for the team to effectively deliver value.

Leadership in Agile projects has multiple layers. Product owners provide visionary leadership. Scrum masters provide process leadership and day-to-day leadership is more situational and generally defused across the entire team. Paul Hersey and Ken Blanchard, leadership gurus and authors, have both written that effective leadership is task-relevant. Task-relevant means that the task will determine the type of leadership and in an Agile who provides that leadership.  The focus of any Agile team changes over the life of project based on both on the stories being worked on and the barriers being addressed. As the focus changes, the mantle of tactical leadership typically changes. In a typical sprint, the product owner’s leadership will be most apparent during story grooming and planning as the focus changes to analysis and construction  development personal provide leadership.  When the focus turns to proving that a story is done the focus changes again and the testing role typically provides leadership until the team drives a story to completion when the cycle begins again. The scrum master facilitates that ebb and flow reflecting their own form of leadership.

The primary role of a scrum master is as a facilitator. That responsibility does not have to be shouldered alone.  All team members are responsible for keeping work flowing, for unsticking work when it gets stuck and for helping to create an environment to maximize the delivery of value. Every member of the team has eyes and ears and within the boundary and intimacy of the team and the responsibility to help each other meet their common goals.

While a product owner prioritizes and a scrum master facilitates, it takes a whole team to deliver.  The whole team is responsible for getting the job done which means that at different times in different situations different members will need to provide leadership. Every team member brings their senses to the project-party, which makes all of them responsible looking for trouble and then helping to resolve it even if there isn’t a scrum master around.


Categories: Process Management

Scrum Master: Five People That Should Not Be A Scrum Master

1480094731_cd4c7e71f0_b

Divided loyalties makes for a bad scrum master. Don’t be a fox watching the hen house!

Not everyone who has the characteristics of a scrum master should be a scrum master. Here are five very simple guidelines to let you know who shouldn’t be the scrum master:

  1. The project or program manager.
    Classic project managers make very poor scrum masters in most cases. Project managers that have plied their trade by directing, controlling and enabling teams are the antithesis of a scrum master. It can be very difficult for project or program managers to shed their role as an enabler. I often see scrum masters with project management backgrounds revert to directing work in periods of stress.
  2. The product owner.
    Ruma Dak talked briefly about this recently on her blog. I agree with the thesis that product ownership is a full time job, making it difficult to do another full time job at the same time.  Even if both roles could be done at once, as the product owner it is very easy to sacrifice the team’s needs to attain more of the business’s needs. This can set up a classic ‘fox watching the hen house’ scenario.  While I strongly believe that having a product owner act as a scrum master is a bad idea, I have seen it work well for a short period of time in one project.  In this circumstance the original scrum master had left the company and the product owner stepped in while a replacement was found. It worked, but it was not sustainable as the product owner already had two jobs (his normal day job and the role of a product owner).
  3. The team’s line manager.
    One of the worst scenarios for the scrum master role is the team’s line manager. I can’t conceive of how this would facilitate the creation of an empowered, self-organizing team. Consider most anything else rather than this option.
  4. The busiest person on the team.
    The next worst person to fill the scrum masters role is the busiest person on the team. Interestingly if you ask for volunteers, this will be the person that is most apt to put their hand up. General rule (you can violate a guideline with proper caution, you should not violate a rule), if the person you want to be the scrum master does have time to do the job well find someone else.
  5. Anyone that does not want to be the scrum master.
    If you do not want to be a scrum master you will not do a good job.

Finding a scrum master begins with understanding the role and finding a person that has the necessary characteristics.  Next, does the person have the time and the passion? Finally consider whether there are conflicts of interests that using a product owner or line manager can cause.


Categories: Process Management

Scrum Master: Who Should Be the Scrum Master?

2014-02-22 09.35.39What are the characteristics of an effective scrum master? Different projects, team and organizations could generate an infinite set of lists with an infinite number of attributes, but the core attributes of a scrum master are:

  • Aggressive Facilitator: We defined a facilitator as someone that helps to unstick something that has stopped moving or creates an environment where progress can be made by the team. An aggressive facilitator actively looks for bottlenecks and environmental issues to maximize the delivery of value.
  • Voice of the scrum process: The scrum master must be the champion of the process.  The ability to champion requires that the scrum master be well versed in Agile processes so that the team can focus on meeting its commitments, rather than making a specific Agile technique fit the team’s need.
  • Acts as servant leader: A servant leader facilitates collaboration not only by creating a learning environment, but also by helping the team to establish a vision and goals. A servant leader builds trust in a variety of ways including providing the team with the environment needed to make decisions and self-organize.
  • High-touch people person: A scrum master needs to be a people person because teams at their most basic level are groups of people pursuing a common goal. The scrum master needs to connect with team members so that he/she can understand their needs, support collaboration and help break down barriers.
  • 110% self-starter: Scrum masters can’t wait to be called upon to facilitate. Scrum masters must be vigilant, observing the ebb and flow of team interactions and by helping to identify and highlight potential barriers to delivery.
  • Team first orientation: Scrum masters need to put aside many of their own needs in order to satisfy the needs of the team. Egocentric leadership tends to confuse their needs and capabilities with those of the team reducing their effectiveness as servant leaders and facilitators.
  • Empathy is the ability to share the emotions and experiences of other makes it easier to put the needs of the team first.  Without empathy, a scrum master will have difficulty building trust with and among team members making it difficult to be a servant leader and a facilitator

An effective scrum master makes the team better by prioritizing the team’s common goal. Staffing a scrum master position is more than just repurposing a project manager or business analyst, rather it is means finding an individual that can facilitate delivering value as part of team.


Categories: Process Management

Keep the Ship of IT Pointed Towards Delivering Value

3216051552_8162e1c778_b

A lecture I attended by Jared Diamond in 2007 changed how I think of IT departments.  His lecture was in support of his book. Collapse: How Societies Choose to Fail or Succeed (2005).  While he wrote about societies, his research is equally relevant to why process improvement programs succeed or fail.  Two of the ideas Dr. Diamond put forth o are instantly germane to SPI programs.  They were:

  • Elites isolate themselves, and
  • An inability to reassess core values

Organizations that leverage the factory model of IT create stovepipes, then assign groups and roles (like SPI) to the stovepipe. This causes isolation.  How many cube farms have you been in where a person in one group may sit next to a person in an another group yet neither know each other’s name (unless is stuck to the outside of the cube)?   The stovepipe/factory model of IT has supported the creation of insular specialists, such as development methodologists, process improvement specialists, project managers and DBAs.  This isolation cuts off decision making groups from those they effect, especially when it comes to support groups like process improvement groups, PPQA and project management.  One management theory suggests that specialization in a production environment is more productive.   I would suggest that in scenarios where there are more knowns than unknowns this type of model can be very efficient.  The model of specialization tends to breakdown in scenarios where the unknowns outweigh the knows and a solution requires interdisciplinary knowledge and interaction.  Using a specialist model in the later scenario reduces efficiency, creates unrest and requires management to expend effort to control work rather than on motivation (a directive versus leadership model).   One of the unintended consequences of putting up barriers is the creation of fertile grounds for grassroots movements (such as teams deciding to use Agile methods on their own or not to use a specific tool). The creation of barriers makes work more difficult leading to a feeling of repression that can only be cured by sweeping away the barriers to getting work done and success.  These cabals may lead to behavior that may or may not be good for the organization. Turning aside the possibility of a popular revolute for a future essay, the isolation of the process improvement ‘elites’ from the general IT population will lead to inefficient solutions.  Involvement allows collaboration; it helps channel change even though overall change uncontrollable but it can dampen it, making it easier for change to generate value.   There many standard methods to try to facilitate a linkage (which different from involvement and collaboration) between groups such as programmed communication, meetings and the like.  The problem is that those solutions tend to feature multiple unidirectional flows of data, people talk at each other rather than to each other.  The standard methods such presentations and deliverable reviews provide spin controlled information but not dialogs and interaction.  In the long run (measured in months not years) the gap between the elites and the general IT population will broaden as the process developers get further away from the real work of an IT organization.

One, tried and true method for making sure the wall stays as thin as possible is to staff process improvement groups primarily from other disciplines (use process improvement as a stepping stone on a career ladder).  Adding open collaboration tools such as WIKISs, RSS feeds and blogs intensifies the interaction and create an intimacy that builds value and community. The goal is to ensure that the decisions made when designing and implementing new processes are tailored toward facilitating work and delivering value.  Involvement requires that those designing and developing processes have to ‘eat their own cooking’, in other words, live by the consequences of their actions in the crucible of software development and maintenance.

The second idea I gleaned from the lecture, the inability to reassess core values, is perhaps a more insidious problem.  Societies, organizations and even teams develop patterns of behavior to guide them.  In IT, we call these patterns frameworks, methodologies and processes.  Without a periodic reassessment of how the organization’s values are supported by implemented methods and processes it is impossible to be sure that the most efficient and effective path will be followed.  If a significant shock to the environment goes unrecognized (a change in technology or globalization) efficiency might be the last thing you worry about as your process choke output.  In short, processes and methods need to be reassessed periodically based on current conditions, organizational needs and values.  Methods and processes should not be elevated to belief structures (e.g. the church of the CMMI, cult of the eXtreme or the commune of Scrum).  What has served you in the past may not serve you in the future.

Involvement and the removal of barriers are important to delivering change that lasts, but aren’t all that is needed to generate continuous value (it is a good start though).  The problem is that change that lasts does not necessarily equate to value. What if it the change starts to impede delivering value as the environment changes?  Transparency, involvement and reassessment of software processes and methods based on current values and needs are the prescription needed to keep the ship of IT pointed towards delivering value.

____________

A version of this essay was originally podcast at www.spamcast.libsyn.com.  Please read and listen.  Comments and suggestions would be appreciated.


Categories: Process Management

Software Development Linkopedia March 2014

From the Editor of Methods & Tools - Wed, 03/12/2014 - 17:06
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about Agile values, roles in Scrum, unit testing mistakes, managing projects, Agile testing, using the MongoDB NoSQL database, software metrics, using programmer anarchy for organizing projects and specifications by example. Web site: Agile Coach Camps Blog: Agile Is Dead (Long Live Agility) Blog: Beyond Roles in Scrum Blog:5 Unit Testing Mistakes Blog: Are comments always wrong? Article: Cutting a Monster Project Down to a Manageable Size Article: When Scrum Uncovers Stinky ...

Scrum Master: A Job Description?

The scrum master helps the team find the right road.

The scrum master helps the team find the right road.

In the movie Independence Day, the US President, played by Bill Pullman, calls on his fellow pilots to help plow the field so that the character played by Randy Quaid can attack the alien craft. Pullman was facilitating Quaid though both a call to action and active participation. The scrum master’s job in most cases is to facilitate plowing the field for the team. Plowing the field creates an environment for a team to grow and deliver value while keeping outside influences from sapping the team’s energy. Here is the scrum master’s job description:

  • Responsible for ensuring that the Scrum practices and rules are followed.
    Ensure that the team is disciplined about the Agile practices and techniques that they have chosen to supports team effectiveness.
  • Teaches the team by coaching and leading.
    The scrum master teaches the team how to use Agile practices and to deal with issues, rather than jumping in and supplanting the team’s actions.
  • Helps the team understand and use self-organization and cross functionality.
    The scrum master fosters an environment that helps the team become a team, rather than a collection of individuals. The scrum master help to create an environment by asking questions, sharing problem solving techniques and mediating interpersonal differences.
  • Removes impediments.
    The scrum master facilitates the resolution of bottlenecks that are blocking the team’s progress.  When impediments are outside of the team’s ability to control (for example waiting on a deliverable from another team or vendor), the scrum master acts will pursue the problem so that others on the team can contiue to be focused on delivering functional software.
  • Ensures that the team keeps itself functional and productive.
    The scrum master needs to observe how the team is working together and to facilitate action when the team is not performing optimally. The scrum master generally makes sure the team knows where they are during a sprint or iteration using tools like the burn down, burn up charts and card walls so that the team can take action.
  • Enables close cooperation across all roles and functions.
    Teams share work, provide support to each other and swarm to tasks or stories when needed.  In order to provide that level of support, it is import for all roles on a team to cooperate. This means that there can’t be a “we-them” relationship between any role on the team. Team sharing and learning sessions are some the the techniques that scrum masters can use to teams learn each others roles and funcitons.
  • Shields the team from external interference.
    At times outsiders will pull at team. External interference is a specialized form of impediment that tends to drain time or focus from the team. The Scrum master will deflect or absorb as many requests that will take the team’s focus away for meeting their commitments and delivering value.

The scrum master needs to create an environment for the team to prosper. The list above outlines the responsibilities that the scrum master must tackle to be effective. As you can see, a scrum master is more than an administrator or planner. The scrum masters facilitates the whole Agile team in attaining their the ultimate measure of value by focusing on the people on the team’s needs and how  they are using the process.


Categories: Process Management