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

Distributed Agile: Backlog Grooming Meetings

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

There are two reasons to hold backlog grooming meetings. The first is to make sprint planning more efficient and effective. The second reason is make sure you understand your backlog. When teams don’t spend the time needed to groom the backlog, planning meetings can be very tense and extend for hours . . . and hours. Backlog grooming sessions can be whole team activities (rare) or sub-team activities (more common). The most common technique used to generate a sub-team for grooming is the Three Amigos (or some variant). The tallest hurdle all distributed teams face is ensuring effective communications, followed quickly by staying focused on the task at hand. Many of the same techniques we discussed for sprint planning in distributed teams will be effective, however backlog grooming has a few unique twists.

  1. Everybody needs to see the story at all times. Everyone involved must be able to see the story being groomed, preferably as it is being edited. Reading a story to someone at the other end of a phone and then amending the reading as you wordsmith the statement is difficult for many people to conceptualize. Most webinar tools now have whiteboard options. Cut and paste the story and acceptance criteria into the whiteboard feature so that everyone can see the words. One team I recently worked with used messaging software to approximate the process (it worked fairly well). Tools like webcams and telepresence can be used, however make sure the story and the acceptance criteria are easily readable by all parties. When a team member can’t hear or see well enough to stay involved, they will lose focus and probably start doing email.
  2. The right people and locations need to be involved. There are many shades of distributed teams, ranging from two locations to completely dispersed (everyone in different locations). The goal of grooming is to make sure the backlog items that may be used in the next sprint are understood, well-formed and have acceptance criteria. Typically, grooming is most effective when the three major team constituencies are to be involved: the business, the developers and the testers. When a team is distributed, locations can become constituencies that need to be involved to ensure that the grooming session attains the goal of making sure the stories are understood. This is an argument for whole team grooming sessions so that no location feels left out.
  3. Use story maps to link stories the big picture. Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play. When a team is distributed, it becomes more difficult for members to have a side conversation to get things back on track or to develop ways to stay aligned to project’s big picture without a more formal reference. A story map provides a frame of reference so that the team members involved in the grooming session can see how the stories fit into overall project. The use of a story map in the grooming process makes it easier to identify or develop a theme for the next sprint (a theme provides focus and direction to the team).

Backlog grooming is a process to make sure the stories that might be used in the next sprint are understood, well-formed and have acceptance criteria. When backlogs are not well groomed teams tend to spend a lot time planning and re-planning rather than delivering value. This is true whether a team is distributed or not. The problem is that when a team is distributed any hiccup takes more effort to fix, making grooming even more important.


Categories: Process Management

Distributed Agile: Daily Stand-up Meetings

Stand-ups are best on your feet!

Stand-ups are best on your feet!

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively is the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective making daily stand-ups work for distributed teams include:

  1. Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might just be starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  3. Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  4. Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. For example ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get competed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams, as well as distributed teams.

  1. Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Others include banning cell phones and side conversations.
  2. Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  3. Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that EVERYONE has access to. Keep tools as simple as possible.
  4. Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing Agile. However despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the Scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.


Categories: Process Management

Handling Requests for Unnecessary Artifacts

Mike Cohn's Blog - Tue, 09/30/2014 - 15: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.

“Working software over comprehensive documentation.” You’ve certainly seen that statement on the Agile Manifesto. It is perhaps the most important of the Manifesto’s four value statements—working software is, after all, the reason a team has undertaken a software development effort.

It is also one of the most misused parts of the Manifesto. This is the quote people cite when trying to get out of all documentation, which is not what the Manifesto says we should value.

Some documentation on a project can be great. But most non-agile teams write too much and talk too little. Some agile teams go to the opposite extreme, but many seem to find a good balance.

Occasionally, though, a team and product owner may disagree on the necessity of a document—usually with the product owner wanting a document and the team saying it’s not necessary. I’ve found two guidelines helpful in determining how to handle requests for various artifacts, especially documentation, on an agile project.

Guideline No. 1: If a team would produce an artifact while in the process of creating working software, that artifact is just naturally produced.

This guideline covers essentially everything a team would want to produce while on the way to building a system or product. It includes, for example, source code. It also includes any design documents, user guides and other items that the team wants to produce for the benefit of the current team, future teams maintaining the software or end users.

Guideline No. 2: If an artifact would not naturally be produced in the process of creating working software, the artifact is added to the product backlog.

The second guideline is there to cover cases when the product owner (or any other outside stakeholder) wants an artifact produced (usually a document) that the team would not normally produce.

For example, suppose the product owner asks the team to write a document describing every table and field in the database. I’ve certainly seen projects where such a document has been extremely helpful. (In fact, I’ve both requested and written such a document before.) But, I’ve always seen projects where this would have been unnecessary.

If the team thought this database description document were helpful, they would produce it in the process of creating the working software. And Guideline No. 1 would apply. But if they don’t think this document is necessary, they won’t produce it. Unless, that is, the product owner insists, which is where Guideline No. 2 comes in.

If the product owner wants this document, the product owner creates a new product backlog item saying so. The team can then estimate the time it will take to develop this document, just like they’d estimate any other product backlog item.

Putting an estimate on creating the document makes its cost explicit. This forces a product owner to think about the opportunity cost of developing that document. The product owner will be able to ponder: This five-point document or five points worth of new features?

I don’t know which the product owner will choose, but this approach makes the cost of that artifact explicit, allowing it to be compared with the value of additional features instead.

I’d love to know your thoughts on this. How does your team handle product owner requests for artifacts the team wouldn’t naturally produce? What artifacts does your team find helpful? Please share your thoughts in the discussion below.

Handling Requests for Unnecessary Artifacts

Mike Cohn's Blog - Tue, 09/30/2014 - 15: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.

“Working software over comprehensive documentation.” You’ve certainly seen that statement on the Agile Manifesto. It is perhaps the most important of the Manifesto’s four value statements—working software is, after all, the reason a team has undertaken a software development effort.

It is also one of the most misused parts of the Manifesto. This is the quote people cite when trying to get out of all documentation, which is not what the Manifesto says we should value.

Some documentation on a project can be great. But most non-agile teams write too much and talk too little. Some agile teams go to the opposite extreme, but many seem to find a good balance.

Occasionally, though, a team and product owner may disagree on the necessity of a document—usually with the product owner wanting a document and the team saying it’s not necessary. I’ve found two guidelines helpful in determining how to handle requests for various artifacts, especially documentation, on an agile project.

Guideline No. 1: If a team would produce an artifact while in the process of creating working software, that artifact is just naturally produced.

This guideline covers essentially everything a team would want to produce while on the way to building a system or product. It includes, for example, source code. It also includes any design documents, user guides and other items that the team wants to produce for the benefit of the current team, future teams maintaining the software or end users.

Guideline No. 2: If an artifact would not naturally be produced in the process of creating working software, the artifact is added to the product backlog.

The second guideline is there to cover cases when the product owner (or any other outside stakeholder) wants an artifact produced (usually a document) that the team would not normally produce.

For example, suppose the product owner asks the team to write a document describing every table and field in the database. I’ve certainly seen projects where such a document has been extremely helpful. (In fact, I’ve both requested and written such a document before.) But, I’ve always seen projects where this would have been unnecessary.

If the team thought this database description document were helpful, they would produce it in the process of creating the working software. And Guideline No. 1 would apply. But if they don’t think this document is necessary, they won’t produce it. Unless, that is, the product owner insists, which is where Guideline No. 2 comes in.

If the product owner wants this document, the product owner creates a new product backlog item saying so. The team can then estimate the time it will take to develop this document, just like they’d estimate any other product backlog item.

Putting an estimate on creating the document makes its cost explicit. This forces a product owner to think about the opportunity cost of developing that document. The product owner will be able to ponder: This five-point document or five points worth of new features?

I don’t know which the product owner will choose, but this approach makes the cost of that artifact explicit, allowing it to be compared with the value of additional features instead.

I’d love to know your thoughts on this. How does your team handle product owner requests for artifacts the team wouldn’t naturally produce? What artifacts does your team find helpful? Please share your thoughts in the discussion below.

Is Agile Dead or Can Good Software Development Scale?

From the Editor of Methods & Tools - Tue, 09/30/2014 - 13:23
As Agile becomes widely accepted as a software development approach, many large organizations have adopted it, mainly in its Scrum form to reduce development cycle. There might be even a fair share of adopters that are trying really to apply Agile values. If the topic of scaling Agile has been discussed for many years and you can read the excellent books of Graig Larman and Bas Vodde on this topic. We have also recently seen the emergence of proprietary” approaches, like SAFE, to achieve this goal. At the same time, ...

Distributed Agile: Sprint Planning

#6 Make sure the telecommunications tools work.

#6 Make sure the telecommunications tools work.

In Distributed Agile: Distributed Team Degree of Difficulty Matrix, I described the many flavors of distributed Agile teams and the complexity different configurations create. While all things being equal, distributed team are less effective than collocated teams. Never the less, distributed Agile with teams spread across countries, continents and companies have become a fact of life. There are techniques to help distributed Agile teams become more effective. In an environment using Scrum, the first formal activities for most team’s is sprint planning. There are numerous techniques that can help make distributed Agile more effective. These techniques include:

1.   Bring the team physically together. Co-location, whether for a single sprint or some periodic basis, will increase the team’s ability to understand each other and know how to work together more effectively.
2.   Develop a sprint planning checklist. The process of getting together and planning is a fairly predictable process. Capture the typical preparation and meeting tasks and make sure they happen. Items can include booking rooms, securing video or telecom facilities, publishing an agenda with breaks and more.
3.   Review the definition of done. Ensure that everyone understands the organization’s definition of done before the starting to plan. The definition of done will help the team know the tasks they need to complete during the sprint to meet the organization’s (or product owner’s) process standards.
4.   Focus on the stories. Don’t let distractions get in the way of planning. Before beginning the planning session, review the process that will be followed with the entire team. Make sure that planning the next sprint is the only topic on the agenda.
5.   Ensure that the stories have been properly groomed. The stories that the team will accept and plan need to be properly formed and have acceptance criteria. This generally means that the stories that are most apt to be accepted by team (and a few more) need to have been through a grooming session. Make this a prerequisite for the planning meeting.
6.   Make sure the telecommunications tools work and have a backup. Distributed planning means that all of the team will be using the phone or video conference. Make sure they are set up and tested. Also always have a backup plan in case your favorite collaboration tool fails because sooner or later it will. Planning is a whole team activity and when the whole team can’t participate planning, it will lose effectiveness.
7.   Everyone should understand the big picture. Have the product owner provide an overview of the goals of the project, and how the current sprint will support those goals. Repeating the big picture will provide the team with a common touch point to validate progress.
8.   Use physical tools for interaction. Physical tools, like flip charts and card walls, can be difficult when many locations are involved in sprint planning. However, when possible, use physical tools like flip charts and whiteboard and then use webcams (preferable) and cameras to share data. Have one location scribe one story and then switch locations for the next story.
9.   Try multiple facilitators. When a team is evenly distributed between two locations consider having another scrum master act as a second facilitator to ensure everyone stays on track. Similarly, have the Scrum master rotate between locations to facilitate the planning session. This can be very effective in helping each location feel connected.
10.Remember that sprint planning is a team meeting. Make sure everyone is involved.

Sprint planning, done well, helps a team understand what they have to do in order to consider a story complete, both from a functional and technical perspective. Distributed Agile teams will need to focus on making sure that everyone is involved and a part of the planning process. Remember to plan for planning, because when you are on the other end of a phone or videoconferencing the tools, process and logistics can make or break the meeting!


Categories: Process Management

SPaMCAST 309 – Agile User Acceptance Testing

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 309

Software Process and Measurement Cast number 309 features our essay on Agile user acceptance testing. Agile user acceptance testing (AUAT) confirms that the output of a project meets the business’ needs and requirements. The concept of acceptance testing early and often is almost inarguable, whether you are using Agile or any other method. AUAT generates early customer feedback, which increases customer satisfaction and reduces the potential for delivering defects. While implementing an effective and efficient AUAT isn’t always easy it most certainly is possible!

The essay begins:

The classic definition of a user acceptance test (UAT) is a process that confirms that the output of a project meets the business needs and requirements. UAT in an Agile project generally is more rigorous and timely than the classic end of project UAT found in waterfall projects. In waterfall projects, the UAT is usually the last step in the development process.  The problem with that classic scenario is that significant defects are found late in the process, or worse, the business discovers that what is being delivered isn’t exactly what they wanted. Agile projects provide a number of opportunities to interject UAT activities throughout the process, starting with the development of user stories, to the sprint reviews and demos, and finally the UAT sprints at the end of a release.  Each level provides a platform for active learning and feedback from the business.

Listen to the rest of the essay, here! —- this will be a link.

Next

SPaMCAST 310 features our interview with Michael Burrows. This is Michael’s second visit to the Software Process and Measurement Cast.  In this visit we discussed his new book, Kanban from the Inside.  The book lays out why Kanban is a management method built on a set of values rather than just a set of techniques. The argument is made that Kanban leads to better outcomes for projects, managers, organizations and customers!

Buy and read the book before the interview!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT

Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

Upcoming Conferences:

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested.

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend 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 309 – Agile User Acceptance Testing

Software Process and Measurement Cast - Sun, 09/28/2014 - 22:00

 Software Process and Measurement Cast number 309 features our essay on Agile user acceptance testing. Agile user acceptance testing (AUAT) confirms that the output of a project meets the business’ needs and requirements. The concept of acceptance testing early and often is almost inarguable, whether you are using Agile or any other method. AUAT generates early customer feedback, which increases customer satisfaction and reduces the potential for delivering defects. While implementing an effective and efficient AUAT isn’t always easy it most certainly is possible!

The essay begins:

The classic definition of a user acceptance test (UAT) is a process that confirms that the output of a project meets the business needs and requirements. UAT in an Agile project generally is more rigorous and timely than the classic end of project UAT found in waterfall projects. In waterfall projects, the UAT is usually the last step in the development process.  The problem with that classic scenario is that significant defects are found late in the process, or worse, the business discovers that what is being delivered isn’t exactly what they wanted. Agile projects provide a number of opportunities to interject UAT activities throughout the process, starting with the development of user stories, to the sprint reviews and demos, and finally the UAT sprints at the end of a release.  Each level provides a platform for active learning and feedback from the business.

Listen to the rest of the essay!

Next

SPaMCAST 310 features our interview with Michael Burrows. This is Michael’s second visit to the Software Process and Measurement Cast.  In this visit we discussed his new book, Kanban from the Inside.  The book lays out why Kanban is a management method built on a set of values rather than just a set of techniques. The argument is made that Kanban leads to better outcomes for projects, managers, organizations and customers!

Buy and read the book before the interview!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT

Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

Upcoming Conferences:

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested.

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend 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

Dazzle Your Audience By Doodling

Xebia Blog - Sun, 09/28/2014 - 10:29

When we were kids, we loved to doodle. Most of us did anyway. I doodled all the time, everywhere, and, to the dismay of my mother, on everything. I still love to doodle. In fact, I believe doodling is essential.

The tragedy of the doodle lies in its definition: "A doodle is an unfocused or unconscious drawing while a person's attention is otherwise occupied." That's why most of us have been taught not to doodle. Seems logical, right? Teacher sees you doodling, that is not paying attention in class, thus not learning as much as you should, so he puts a stop to it. Trouble is though, it's wrong. And it's not just a little bit wrong, it's totally and utterly wrong. Exactly how wrong was shown in a case study by Jackie Andrade. She discovered that doodlers have 29% better recall. So, if you don't doodle, you're doing yourself a disservice.

And you're not just doing yourself a disservice, you're also doing your audience a disservice. Neurologists have discovered a phenomenon dubbed "mirror neurons." When you see something, the same neurons fire as if you were doing it. So, if someone shows you a picture, let's say a slide in a presentation, it is as if you're showing that picture to yourself.

Wait, what? That doesn't sound special at all, now does it? That's why presentations using only slides can be so unintentionally relaxing.

Now, if you see someone write or draw something on a flip chart, dry erase board or any other surface in plain sight, it is as if you're writing or drawing it yourself. And that ensures 29% better recall. Better yet, you'll remember what the presenter wants you to rememeber. Especially if he can trigger an emotional response.

Now, why is that? At EUVIZ in Berlin last month, I attended a presentation by Barbara Siegel from Look2Listen that changed my life. Barbara talked about the latest insights from neuroscience that prove that everyone feels first and thinks later. So, if you want your audience to tune in to your talk, show some emotion! Want people to remember specific points of your talk? Trigger and capture emotion by writing and drawing in real-time. Emotion runs deep and draws firm neurological paths in the brain that help you recreate the memory. Memories are recreated, not stored and retrieved.

Another thing that helps you draw firm neurological paths is exercise. If you get your audience to stand up and move, you increase their brain activity by 7%, hightening alertness and motivation. By getting your audience to sit down again after physical exercise, you trigger a rebalancing of neurotransmitters and other neurochemicals, so they can use the newly spawned neurons in their brain to combine into memories of your talk. Now that got me running every other day! Well, jogging is more like it, but hey: I'm hitting my target heart-rate regularly!

How does this help you become a better public speaker? Remember these two key points:

  1. At the start of your speech, get your audience to stand up and move to ensure 7% more brain activity and prime them for maximum recall.
  2. Make sure to use visuals and metaphors and create most, if not all, of them in real-time to leverage the mirror neuron effect and increase recall by 29%.

Value Is More Than Quality

A good fruit salad requires balance.

A good fruit salad requires balance.

In the Software Process and Measurement Cast 308, author Michael West describes a scenario in which a cellphone manufacturer decided that quality was their ultimate goal. The handset that resulted did not wow their customers. The functionally wasn’t what was expected and the price was prohibitive. The morale of the story was that quality really should not have be the ultimate goal of the project. At the time I recorded the interview I did not think the message Mr. West was suggesting was controversial. Recently I got a call on Skype. The caller had listened to the podcast and read Project Success: A Balancing Act and wanted to discuss why his department’s clients were up in arms about the slow rate of delivery and the high cost of projects. Heated arguments had erupted at steering committee meetings and it was rumored that someone had suggested that if the business wanted cheaper products that IT would just stop testing. Clearly focusing on the goal of zero defects (which was equated to quality) was eliciting unproductive behavior. Our discussion lead to an agreement that a more balanced goal for software development, enhancement or maintenance projects is the delivery of maximum value to whoever requested the project.

When a sponsor funds and sells a project they communicate a set of expectations. Those exceptions typically encompass a project will deliver:

  1. The functionality needed to meet their needs,
  2. The budget they will spend to acquire that functionality,
  3. When want the functionality, and
  4. The level of quality required to support their needs.

Each expectation is part of the definition of value. A project that is delivered with zero defects two years after it is need is less valuable than a project delivered when needed that may have some latent minor defects. A project that costs too much uses resources that might be better used to do another project or potentially causes an organization products to be priced out of the market. Successful projects find a balance between all expectations in order to maximize the value that is delivered.

Quality is not the ultimate goal of any software development, enhancement or maintenance project but neither is cost, schedule or even functionality. Value is the goal all project should pursue. Finding and maintaining equilibrium between the competing goals of cost, schedule and functionality is needed to maximize the ultimate value of a project. Each project will have their own balance based on the context of the project. Focusing on one goal to the exclusion of all others represents an opportunity cost. Every time we face a decision that promotes one goal over another, we should ask ourselves whether that choice is worth giving focus over another goal. Projects that focus on value create an environment in which teams, sponsors and organizations confront the trade-offs goals like zero-defects or perfect quality can cause.


Categories: Process Management

Kanban And The Theory of Constraints

A dam releasing water is an  example of flow through a constraint.

A dam releasing water is an example of flow through a constraint.

The Theory of Constraints (ToC), as defined by Eli Goldratt in the book The Goal (1984), is an important concept that shapes how we measure and improve processes.  ToC takes a systems thinking approach to understanding and improving processes. A simple explanation of ToC is that the output of any system or process is limited by a very small number of constraints within the process. Kanban is a technique to visualize a process, manage the flow of work through the process and to continually tune the process to maximize flow that can help you identify the constraints. There are three critical points from the ToC to remember when leveraging Kanban as a process improvement tool.

  1. All systems are limited by a small number of constraints. At any specific point in time, as work items flows through a process, the rate of flow is limited by the most significant constrained step or steps. For example, consider the TSA screening process in an Untied States airport. A large number of people stream into the queue, a single person checks their ID and ticket, passes them to another queue where people prepare for scanning, and then both people and loose belongings are scanned separately, are cleared or are rescanned, and finally the screened get to reassemble their belongings (try doing that fast). The constraint in the flow is typically processing people or their belongings through the scanner. Flow can’t be increased by adding more people to check IDs because that is not typically the constraint in the flow. While each step in a process can act as a constraint based on the amount of work a process is asked to perform or if a specific circumstance occurs (the ID checker has to step away and is not replaced, thereby shutting down the line), however, at any one time the flow of work is generally limited by one or just a few constraints.
  2. There is always at least one constraint in a process. No step is instantly and infinitely scalable. As the amount of work a is being called on to perform ebbs and flows there will be at least one constraint in the flow. When I was very young my four siblings and I would all get up to go to school roughly at the same time. My mother required us to brush our teeth just before leaving for school. The goal was to get our teeth cleaned and out of the bathroom so that we could catch the bus as quickly as possible. We all had a brush and there was plenty of room in the bathroom, however there was only one tube of toothpaste (constraint). One process improvement I remember my mother trying was to buy more tubes of toothpaste, which caused a different problem to appear when we began discussing who’s tube was who’s (another constraint). While flow was increased, a new constraint emerged. We never found the perfect process, although we rarely missed the bus.
  3. Flow can only be increased by increasing the flow through a constraint. Consider drinking a milkshake through a straw. In order to increase the amount of liquid we get in our mouth we need to either suck on the straw harder (and that will only work until the straw collapses), change the process or to increase capacity of the straw. In the short-run sucking harder might get a bit more milkshake through the straw but if done for any length of time the additional pressure will damage the “system.”  In the long run the only means to increase flow is either change the size of the straw or change the process by drinking directly from the glass. In all cases to get more milkshake into our mouth we need to make a change so that more fluid gets through the constraint in the process.

The Theory of Constraints provides a tool to think about the flow of work from the point of view of the constraints within the overall process (systems thinking).  In most process, just pushing harder doesn’t increase the output of a process beyond some very limited, short-term improvement. In order to increase the long-term flow of work through a process we need identify and remove the constraints that limit the flow of value.


Categories: Process Management

Labor Productivity: An Excerpt From The Metrics Minute

Productivity is number of clothes sewed per hour.

Productivity is number of clothes sewed per hour.

Definition:

Labor productivity measures the efficiency of the transformation of labor into something of higher value. It is the amount of output per unit of input: an example in manufacturing terms can be expressed as  X widgets for every hour worked. Labor productivity (typically just called productivity) is a fairly simple manufacturing concept that is useful in IT. It is a powerful metric, made even more powerful by it’s simplicity. At its heart, productivity is a measure of the efficiency of a process (or group of processes). That knowledge can be tool to target and facilitate change. The problem with using productivity in a software environment is the lack of a universally agreed upon output unit of measure.

The lack of a universally agreed upon, tangible unit of output (for example cars in an automobile factory or steel from a steel mill) means that software processes often struggle to define and measure productivity because they’re forced to use esoteric size measures. IT has gone down three paths to solve this problem. The three basic camps to size software include relative measures (e.g. story points), physical measures (e.g. lines of code) and functional measures (e.g. function points). In all cases these measures of software size seek to measure the output of the processes and are defined independently of the input (effort or labor cost).

Formula:
The standard formula for labor productivity is:

Productivity = output / input

If you were using lines of code for productivity, the equation would be as follows:

Productivity = Lines of Code / Hours to Code the Lines of Code

Uses:
There are numerous factors that can influence productivity like skills, architecture, tools, time compression, programming language and level of quality. Organizations want to determine the impact of these factors on the development environment.

The measurement of productivity has two macro purposes. The first purpose is to determine efficiency. When productivity is known a baseline can be produced (line in the sand) then compared to external benchmarks. Comparisons between projects can indicate whether one process is better than another. The ability to make a comparison allows you to use efficiency as a tool in a decision-making process. The number and types of decisions that can be made using this tool are bounded only by your imagination and the granularity of the measurement.

The second macro rational for measuring productivity is as a basis for estimation. In its simplest form a parametric estimate can be calculated by multiplying size by a productivity rate.

Issues:
1. The lack of a consistent size measure is the biggest barrier for measuring productivity.
2. Poor time accounting runs a close second. Time account issues range from misallocation of time to equating billing time to effort time.
3. Productivity is not a single number and is most accurately described as a curve which makes it appear complicated.

Variants or Related Measures:
1. Cost per unit of work
2. Delivery rate
3. Velocity (agile)
4. Efficiency

Criticisms:
There are several criticisms of the using productivity in the software development and maintenance environment. The most prevalent is an argument that all software projects are different and therefore are better measured by metrics focusing on terminal value rather than by metrics focused on process efficiency (artesian versus manufacturing discussion). I would suggest that while the result of a software project tends to be different most of the steps taken are the same which makes the measure valid but that productivity should never be confused with value.

A second criticism of the use of productivity is a result of improper deployment. Numerous organizations and consultants promote the use of a single number for productivity. The use of a single number to describe the productivity the typical IT organization does match reality at the shop floor level when the metrics is used to make comparisons or for estimation. For example, would you expect a web project to have the same productivity rate of a macro assembler project? Would you expect a small project and a very large project to have the same productivity? In either case the projects would take different steps along their life cycles therefore we would expect their productivity to be different. I suggest that an organization analyze their data to look for clusters of performance. Typical clusters can include: client server projects, technology specific projects, package implementations and many others. Each will have a statistically different signature. An example of a productivity signature expressed as an equation is shown below:

Labor Productivity=46.719177-(0.0935884*Size)+(0.0001578*((Size-269.857)^2))

(Note this is an example of a very specialized productivity equation for a set of client server projects tailored for a design, code and unit testing. The results would not representative a typical organization.)

A third criticism is that labor productivity is an overly simple metric that does not reflect quality, value or speed. I would suggest that two out three of these criticisms are correct. Labor productivity is does not measure speed (although speed and effort are related) and does not address value (although value and effort may be related). Quality may be a red herring if rework due to defects is incorporated into productivity equation. In any case productivity should not be evaluated in a vacuum. Measurement programs should incorporate a palette of metrics to develop a holistic picture of a project or organization.


Categories: Process Management

Software Development Conferences Forecast September 2014

From the Editor of Methods & Tools - Thu, 09/25/2014 - 09:56
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing and software quality, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. Future of Web Apps, September 29-October 1 2014, London, UK STARWEST, October 12-17 2014, Anaheim, USA Register and save up with code SW14MT JAX London, October 13-15 2014, London, UK Pacific Northwest Software Quality Conference, October 20-22 2014, Portland, USA Agile ...

Kanban: Work-In-Process

5971668666_29ef58927d_b

When discussing lean techniques such as Kanban, we often assume that you understand the concept of work-in-process (WIP). That assumption is not always true. I am occasionally asked how WIP is defined in a software development (or an enhancement or maintenance project) and whether related work products, like test plans or documentation, are part of WIP for piece of code.

WIP is work that has entered the production process, but is not yet complete. A slightly more technical definition of WIP is all raw materials or partially finished product that are used or transformed in the production process. In a software development or maintenance project, WIP includes all of the work products or resources required to deliver valuable functionality. In software development and maintenance, WIP for the story will typically include code, documentation, test cases, test results and plans (just to name a few typical work products). All of these work products are WIP until the story is deployed in production.

In the Kanban: An Overview and Introduction we used a simple software development lifecycle to define Kanban and the concept of flow. Using a user story as an example we can trace the transformation from a card into implemented software. The story begins its WIP journey as soon as is pulled out of the backlog and then completes WIP journey when it has been deployed in production. The simple Kanban workflow we used in the past is shown below:

Untitled

Using the example of simple piece of web functionality we begin with the user story, “As a SPaMCAST listener I want to see the description of the book by current interviewee so I can decide to buy the book.” As soon as I grab the card and put it into the analysis column it is WIP. This is true whether I start fleshing out the user story at that exact moment or later in the day. In order to complete this story it requires that I create a link to the book and embed that link in the blog entry for the podcast episode and then test the link to ensure that it works. The link is complete when the blog entry is in production and the story is no longer WIP. Diving down a little into the detail, when I create the book link I go to the booksellers site (SPaMCAST uses an Amazon affiliate account so that purchases of the books mentioned on the podcast support offsetting the expenses needed to provide the podcast) and select the link for the book. The next step is to paste the link into an Evernote document for documentation purposes. That Evernote document becomes part of the WIP connected to the story. Later if that the link is found to be wrong, not only does the link in the blog entry need to be changed, the link in the documentation will need to be updated. Nothing ceases to be WIP until the link is live on the website and it works correctly. As the story progresses the link is embedded it into podcasts blog entry, the link is tested using a simple test plan (the test plan is part of the WIP related to the story). During the process of finding the link and putting it into the blog entry and Evernote document, the story is being worked on,. When the story is is being actively worked on the story is moving through the process (flow). When the link is embedded and tested the code is complete and ready to be implemented. Ready to be implemented is not same as being implemented. In process for the SPaMCAST podcast, the story is still WIP, but it is no longer being worked on. The flow of the story has been interrupted. If the blog entry or whole podcast needed to be updated the link would need to be revalidated and potentially changed. The listeners of the Software Process and Measurement Cast will know that the podcast typically goes live on Sunday at 17:00 Eastern Time. As soon as the link is validated in production the story moves from WIP to complete.

When discussing WIP in software development it is easy to fixate on the functional software as the only part of the story when tracing WIP. In the example of the book link user story, the process I use to develop the link and ensure that it works includes code (HTML), documentation and a simple test plan. All of these work products are part of the completing the user story. Completion of one work product without the other leaves the story in an incomplete state and still work-in-process.


Categories: Process Management

Kanban: Software Development Kanban and Little’s Law

15055728837_58664443cc_k

throughput

Kanban is a methodology for shaping and controlling the flow of work through a process. Kanban as a method was popularized and honed though its application in lean manufacturing, specifically in the Toyota Production System. The manufacturing pedigree of Kanban led to application of lean and other engineering concepts such as queuing theory. Little’s Law is a mathematical observation that the number of customers in a system equals the average arrival rate multiplied by the average time the customer is “in” the system. Knowing the average time a customer is in process can be used to judge how many resources should be applied or whether changes speed the process up. Lean and Kanban adherents shift the focus from arrival rate to output, which is more interesting in development and manufacturing environments. Many Kanban implementations use Little’s Law to help forecast and measure throughput.

Little’s Law is typically stated in lean/Kanban circles as:

Cycle Time = Work-in-process/Throughput

Work-in-process (WIP) is the amount of units of work between the start and end points of the process. WIP is measured using the same unit of measure that you used to measure throughput. Use story points for velocity, function points for productivity and stories for #NoEstimates.

Throughput is the average output of the process. Examples of development throughput are velocity (average story points delivered per sprint), productivity (function points per person month) or simply as the average number of stories completed in a sprint (this could be explored by the adherents of #NoEstimates).

Here is an example calculation based on a Kanban implementation I reviewed:

  • Current WIP: 175 story points
  • Throughput: 47 story points per period (two weeks)
  • Cycle time: 175/47 = 3.7 periods or 37.2 days (10 working days per period)

Cycle time, based on Little’s Law, is useful for release planning, monitoring flow and judging whether process improvements are effective in reducing cycle time. Having a measure that informs an organization how fast work transits a specific process can be used to plan when an item from the backlog will enter the process (an item is pulled into a Kanban process when there is capacity to begin work) and when it will be complete. This type of information is critical for informed release planning. If we apply the cycle time metric to monitoring cycle time improvements, it should provide the organization with a means of monitoring and measuring whether throughput is improving.

Little’s Law as typically applied by practitioners of lean and Kanban effectively provides a process throughput metric by measuring cycle time. The original application of Little’s Law focused on waiting time in the queue (how long items sat in the backlog). The current interpretation of Little’s Law is more useful for development organizations trying to maximize output rather than minimizing the backlog wait time.


Categories: Process Management

Critiquiting One of My Own Real User Stories

Mike Cohn's Blog - Tue, 09/23/2014 - 15:00

In case you haven’t noticed, a few months ago we launched Front Row Agile, a site dedicated to video training courses on agile and Scrum. This has placed me in the role of product owner for the site. And recently, the team on the project criticized my story writing! It was a valid criticism, so I want to share it here.

As you’d expect on a video training site, someone who buys a course is asked to review the course after watching it. Unfortunately very few course participants were leaving reviews. In fact, we’d only had one review given.

I looked into why this was so and discovered that when a course was complete, our on-screen request for a review was hard to notice. See the following image to see what I mean.


 

 

 

 

 

 

 

After seeing that, I added a user story to our product backlog:

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review.

And this was the story the team member didn’t like. He told me that this story made total sense for the participant taking action, but he said he would have written this:

As Front Row Agile, I want participants to be encouraged to review a course after finishing the course, so we can have more feedback about how folks like our courses.

The developer was right—there were a couple of possible problems with the story as I wrote it.

Jumping Right into How

First, the story I wrote bypassed what was needed and jumped right into how we would solve the problem. In general, product backlog items should start with the goal of the change being made to the system. The goal here was to get more reviews.

The goal was not a more prominent call to action. A more prominent call to action was how I thought we could achieve what we wanted.

However, I was very aware of this when I wrote the story and deliberately wrote the story to say how I wanted a change made.

I had already spoken to the designer about the lack of reviews, and he and I agreed that the call to action asking for a review needed to be more prominent. It would have been wrong of me to say I was open to any solution that achieved a goal of more reviews when I, as the product owner, had already decided on what I wanted.

I wrote this story as I did so that it would remind the designer of what we’d already discussed. If I’d written it in some more vague way, the designer would have wondered, “Is the story Mike wanted about improving the call to action to get reviews?”

Minimally, though, I should have added an explicit “so that” clause to the story:

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review, so that there are more reviews on the site.

Writing for the Right User

The developer also criticized my story for being about the course participant rather than about Front Row Agile itself or perhaps me as the site’s owner. That is, rather than start with “As a participant…” perhaps I should have written, “As Front Row Agile …”

I try to write stories that put the reader in the most useful state of mind for understanding the story. Generally, that means I’ll write a story about the actor in the story. In this case, Front Row Agile isn’t doing anything; the course participant is. So, I wrote the story from that perspective.

So Which Story Is Better?

This leaves us with the question of which story is better?

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review.

As Front Row Agile, I want participants to be encouraged to review a course after finishing the course, so we can have more feedback about how folks like our courses.

I’m going to fall back on the old standby answer of: “It depends.”

The “As a participant” story is better in the case where a product owner and team have discussed what is needed, settled on a solution, and the story is just reminding everyone involved of what has already been decided.

The “As Front Row Agile” story is better when the product owner is open to any number of possible solutions to solving a problem. If the Front Row Agile call to action asking for reviews had already been more prominent, I would prefer the second story above.

This would have shown that I was open to things like simply rewording the text, perhaps sending an email to participants after they finish a course, or perhaps moving the call to action to another screen entirely.

There are very few hard and fast rules in writing user stories. Even things like “write a story from the perspective of the person who benefits from the story” can best be thought of as guidelines.

What do you think? Do you have any similar examples?

Critiquing One of My Own Real User Stories

Mike Cohn's Blog - Tue, 09/23/2014 - 15:00

In case you haven’t noticed, a few months ago we launched Front Row Agile, a site dedicated to video training courses on agile and Scrum. This has placed me in the role of product owner for the site. And recently, the team on the project criticized my story writing! It was a valid criticism, so I want to share it here.

As you’d expect on a video training site, someone who buys a course is asked to review the course after watching it. Unfortunately very few course participants were leaving reviews. In fact, we’d only had one review given.

I looked into why this was so and discovered that when a course was complete, our on-screen request for a review was hard to notice. See the following image to see what I mean.


 

 

 

 

 

 

 

After seeing that, I added a user story to our product backlog:

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review.

And this was the story the team member didn’t like. He told me that this story made total sense for the participant taking action, but he said he would have written this:

As Front Row Agile, I want participants to be encouraged to review a course after finishing the course, so we can have more feedback about how folks like our courses.

The developer was right—there were a couple of possible problems with the story as I wrote it.

Jumping Right into How

First, the story I wrote bypassed what was needed and jumped right into how we would solve the problem. In general, product backlog items should start with the goal of the change being made to the system. The goal here was to get more reviews.

The goal was not a more prominent call to action. A more prominent call to action was how I thought we could achieve what we wanted.

However, I was very aware of this when I wrote the story and deliberately wrote the story to say how I wanted a change made.

I had already spoken to the designer about the lack of reviews, and he and I agreed that the call to action asking for a review needed to be more prominent. It would have been wrong of me to say I was open to any solution that achieved a goal of more reviews when I, as the product owner, had already decided on what I wanted.

I wrote this story as I did so that it would remind the designer of what we’d already discussed. If I’d written it in some more vague way, the designer would have wondered, “Is the story Mike wanted about improving the call to action to get reviews?”

Minimally, though, I should have added an explicit “so that” clause to the story:

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review, so that there are more reviews on the site.

Writing for the Right User

The developer also criticized my story for being about the course participant rather than about Front Row Agile itself or perhaps me as the site’s owner. That is, rather than start with “As a participant…” perhaps I should have written, “As Front Row Agile …”

I try to write stories that put the reader in the most useful state of mind for understanding the story. Generally, that means I’ll write a story about the actor in the story. In this case, Front Row Agile isn’t doing anything; the course participant is. So, I wrote the story from that perspective.

So Which Story Is Better?

This leaves us with the question of which story is better?

As a participant who has just finished a course, I'd like a more prominent call to action asking me for a review.

As Front Row Agile, I want participants to be encouraged to review a course after finishing the course, so we can have more feedback about how folks like our courses.

I’m going to fall back on the old standby answer of: “It depends.”

The “As a participant” story is better in the case where a product owner and team have discussed what is needed, settled on a solution, and the story is just reminding everyone involved of what has already been decided.

The “As Front Row Agile” story is better when the product owner is open to any number of possible solutions to solving a problem. If the Front Row Agile call to action asking for reviews had already been more prominent, I would prefer the second story above.

This would have shown that I was open to things like simply rewording the text, perhaps sending an email to participants after they finish a course, or perhaps moving the call to action to another screen entirely.

There are very few hard and fast rules in writing user stories. Even things like “write a story from the perspective of the person who benefits from the story” can best be thought of as guidelines.

What do you think? Do you have any similar examples?

Coding Dojos, Agile Metrics and Specifications in Methods & Tools Fall 2014 issue

From the Editor of Methods & Tools - Tue, 09/23/2014 - 13:45
Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Fall 2014 issue that discusses better coding with Coding Dojos, Lean Agile metrics, the difference between requirements and specifications, software testing, java code conventions and project management open source tools. Methods & Tools Fall 2014 contains the following articles: * The Coding Dojo – a Forum for Improving your Coding Skills * Lean Agile Metrics for Scaled Agile Systems * Something Old, Something New: Requirements and Specifications * CatJS – Testing HTML and JavaScript * Applying Java ...

Kanban: The Difference Between Constraints and Bottlenecks

IMG_3635The work performed to develop, test and implement any software package is a process flow. Not every team or organization will follow the same flow. Many factors can influence the flow of the work in order to deliver maximum value. Kanban is a popular technique to help a team or organization visualize, control and improve the flow of work so that more value is delivered. Kanban is especially valuable because the visualization exposes bottlenecks and constraints. When applying Kanban, one of the values implicit is adopting wait and see approach to making process changes.  In Kanban, you only make changes when data exposes a constraint or bottleneck. The determination of whether any flow problem is a constraint or bottleneck will affect how they are solved. While similar, bottlenecks and constraints are different and these differences drive how we address them.

A bottleneck is a resource that has a capacity that is less to demand placed on that resource while a constraint is a physical factor that limits performance. Applied to the typical software development or enhancement project, resources typically reflect the amount of effort people can apply. A tester with a backlog of 100 hours of testing to perform would be a bottleneck.  In the same development environment, an example of a constraint would be if the organization had one system testing environment and two teams wanted to use that at the same time and could not due to systemic conflicts. The limitations in the environment would be a constraint. Bottlenecks can be solved by changing or adding resources while constraints require changing the environment as part of changing resources.

Our poor tester is saddled with a backlog of 100 hours of testing.  The backlog reflects a work in progress that is sitting, waiting to be tested to determine whether the code works and meets business requirements. Defects in that code can potentially impact other work that is currently waiting to be tested, currently being coded or work that has previously tested, therefore waiting to test delays feedback.  Two simple changes can be made to improve flow.  The first is slow the amount of work coming to the tester so that work gets to the tester just when it can be tested (reduce the amount of code being written or changed) or increase the number of testers (real or virtual). To remove the bottleneck the organization could reduce the amount of work that needs to be tested or increase the capacity of testing by adding tester. Bottlenecks can be solved by adding, rearranging or reducing resources used in the overall process without changing the environment..

In the article Kanban: Process Improvement and Bottlenecks we used the metaphor of water pouring from a bottle to visualize bottlenecks.  The neck of the bottle is a constraint. If the goal was to improve flow would need limit the amount of water entering the neck of the bottle or remove the constriction.  Adding more neck to the bottle would not affect the flow positively.  In our testing environment example, in order to improve the flow and reduce waiting we would either have to plan project work better so that only one group wanted to use the environment at a time or make a physical change to the test architecture by adding a second (or perhaps more) system test environment.  In order to solve constraints the environment must be changed to solve the flow issue (other resources may also be changed in addition).

Note – Either case requires an overall systems view of the development and enhancement process used by the organization or team. This ensures that removing one constraint or bottleneck just doesn’t create another!

The difference between bottlenecks and constraints may seem to be overly nuanced however understanding that a constraint can be addressed by adjusting resources whereas a bottleneck will require physical changes to the environment is critical to ensuring effective change.

 


Categories: Process Management

Xebia KnowledgeCast Episode 4: Scrum Day Europe 2013, OpenSpace Knowledge Exchange, and Fun With Stickies!

Xebia Blog - Mon, 09/22/2014 - 16:44

xebia_xkc_podcast
The Xebia KnowledgeCast is a bi-weekly podcast about software architecture, software development, lean/agile, continuous delivery, and big data. Also, we'll have some fun with stickies!

In this fourth episode, we share some impressions of Scrum Day Europe 2013 and Xebia's OpenSpace Knowledge Exchange. And of course, Serge Beaumont will have Fun With Stickies! First, we interview Frank Bakker and Evelien Roos at Scrum Day Europe 2013. Then, Adriaan de Jonge and Jeroen Leenarts talk about continuous delivery and iOS development at the OpenSpace XKE. And in between, Serge Beaumont has Fun With Stickies!

Frank Bakker and Evelien Roos give their first impressions of the Keynotes at Scrum Day Europe 2013. Yes, that was last year, I know. New, more current interviews are coming soon. In fact, this is the last episode in which I use interviews that were recorded last year.

In this episode's Fun With Stickies Serge Beaumont talks about hypothesis stories. Using those, ensures you keep your Agile really agile. A very relevant topic, in my opinion, and it jells nicely with my missing line of the Agile Manifesto: Experimentation over implementation!

Adriaan de Jonge explains how automation in general, and test automation in particular, is useful for continuous delivery. He warns we should focus on the process and customer interaction, not the tool(s). That's right before I can't help myself and ask him which tool to use.

Jeroen Leenarts talks about iOS development. Listening to the interview, which was recorded a year ago, it's amazing to realize that, with the exception of iOS8 having come out in the mean time, all of Jeroen's comments are as relevant today as they were last year. How's that for a world class developer!

Want to subscribe to the Xebia KnowledgeCast? Subscribe via iTunes, or use our direct rss feed.

Your feedback is appreciated. Please leave your comments in the shownotes. Better yet, use the Auphonic recording app to send in a voicemessage as an AIFF, WAV, or FLAC file so we can put you ON the show!

Credits