Skip to content

Feed aggregator

Don’t assume a 30% allocation for testing on software budgets.

NetObjectives - Fri, 12/02/2016 - 12:24
The software engineering field has changed a lot over the years. There have been many advances in the field in terms of tools used, how teams build and test software, the speed of delivery, etc…   For teams that have not yet become a true agile team (every sprint is developed, tested and production ready), there is one pattern that continues to show itself, even though this pattern is a carry...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Why 2016 Sucked for Techies

About SCRUM - Hamid Shojaee Axosoft - Wed, 11/30/2016 - 18:00

Depending on who you ask, 2016 kind of sucked. Some high profile deaths like David Bowie, Alan Rickman – even Prince, for goodness sake – have left us pretty bummed out. It’s against this calamitous backdrop that I introduce 4 tech products that also left us, perhaps too early?

Samsung Galaxy Note 7

In August, Samsung released the mother of all phablets, the Galaxy Note 7. With excellent specs, a dreamy blue color variant and an improved S Pen, it looked like the hottest phone on the market, until it literally became the hottest, most explodey phone on the market!

Users started reporting that their phones were exploding. Samsung introduced a global recall, at great expense, and hurried out a ‘safe’ replacement.

You know where this is going… They failed to tackle the whole ‘exploding’ part. So, more phones burned up, and faster than you could say “wait, I’m sure we had a billion dollars more than this,” the Note 7 was banned on flights and finally discontinued permanently. Some people (not Samsung) saw the funny side and even made a GTA V mod where they replaced bombs with Note 7s (there are some extremely violent demos on YouTube if you’re interested).

Samsung were not amused by this GTA mod
Samsung was not amused by this GTA mod

The debacle was actually a real shame. Aside from the fact that these phones were explosives waiting to detonate without warning—possibly right next to you as you slept in bed—the Note 7 was an excellent phone, with a design to rival Apple’s best efforts. It was the kind of contender in the market that pushes others to innovate. It was a smoking phone. It blew the others out of the water. RIP Samsung Galaxy Note 7.

Note: Things got even worse for Samsung in November after a number of their washing machines started exploding too. That’s right: yet another device you won’t be able to take on an airplane. Fantastic.


Twitter’s six-second, looped, video clip service was one of the ultimate creative constraints. Vine became the source of many strange, useless and hilarious videos, often made funnier by their short looping. In October this year, Twitter stopped allowing new Vines to be uploaded to the service.

It’s such frustrating irony that a six-second Vine would probably prove the perfect medium through which to express the sorrow at Vine’s demise.

Here are some fun memories, best enjoyed with sound:

The Headphone Jack

In a divisive move, Apple released the new iPhone 7s in September, sans headphone jack. Apple’s Phil Schiller sounded more than a little like a Silicon Valley character when he attributed the axing of the jack to having “[the] courage to move on and do something new that betters all of us.”

Apple has a history of getting rid of technologies it deems out of date, and to their credit, the company often makes the right call, helping to push the market forward (anyone still using a floppy disk or optical drive in their machine?). Only time will tell on this one, but the pricey and delayed Airpods haven’t helped many people warm up to the idea, yet.

Function Keys

Drunk on courage, the Apple team then went on to banish the function keys on most of the new MacBook Pros to the annuls of history. Now, the new Touch Bar provides an OLED touch screen to offer contextual touch keys.

The MacBook Pro touch bar
The MacBook Pro touch bar

This isn’t a deal-breaker for most people, but some people may find themselves lamenting over the lack of a physical Esc key (here’s a decent tip for getting around that) and the reassuring clickety-clack of the function keys. However, designers (and potentially coders, when support for the bar catches up) might find the contextual touch keys a real time-saver when flicking between tools or performing repeated tasks.

I’ve played with this, and it’s actually a really practical hardware revision. Still in its infancy, it needs more active third-party support, but it already has the Apple stock apps covered. Plus, third party developers are starting to jump on board. This useful post rounds up currently supported apps!

Sure, the Touch Bar presents another piece of software that could crash, but, that also means it’s another piece of software that can be hacked:

Categories: Companies

Practicing Agile with HR Teams

Leading Agile - Wed, 11/30/2016 - 15:18

A conversation with Enterprise Transformation Consultant Jeff Howey about Agile practices being used outside of IT organizations.

How did you start working in HR?

When I started working with the HR business organization, it was actually helpful that most of the technology teams were individually running with a basic form of Scrum or Kanban already. The leaders of the business area understood the value of visibility, predictability and adaptability that were improving through the practice of Agile in the technology teams. They knew they also wanted predictability, to focus on value, to make and meet promises out of the HR business unit. So they asked me to help their teams in Human Resources. Teams like recruiting, learning and development, compensation and various other groups within the actual HR services area practice some of those agile techniques.

What were some challenges working with the non-IT groups?

One of the key things that was interesting was that I had to change some of the language that I’m used to using as an agile coach. For instance, to use the word Scrum with someone whose job has been helping to coach and lead people in conflict resolution and explain its roots in the somewhat violent game of Rugby, created a bit of a angst within the group. So I had to make some simple changes. Instead of Kanban, I talked to them about a visual management system. Our goal as a team is to know all the work we are doing and manage it in a visual way so we can see it where it’s at, where it’s moving, where it might be getting stuck. That resonated. In a non-technical environment it’s the concepts that apply and the language that we use can sometimes get in the way.

Besides language were there other impediments that you found?

There were some obvious problems. Pretend you’re a caseworker on an employee relations team, that is dealing with an employee that just kicked their boss. Now the system we are trying to create is a visual management system where everything is on cards and everyone can see what you’re working on. The last thing you want to do is make a card that the whole organization can see that says that someone has kicked their boss and is going to get fired. There is a limit, sometimes even legally, to the amount of transparency that you can have.

There were also some teams that simply opted out because they had ideas around privacy and privileged information and things that are confidential or just messy which they felt couldn’t be managed this way. And a few individuals who were specialists that felt it was too much overhead to be managed this way.

How did you address these impediments?

Let’s start with the teams that adopted it easily. One of the concerns of the teams was specialization, “I’m the one that does this and you’re the one that does that.” When I asked why, the answer was more often than not, “because that’s the way it’s always been.” So I began to discuss why you might want to share responsibilities, things like succession planning, back-ups for vacations and illness and introduced the concept of pairing. The patterns that we see in technology we are able to apply to a non-technical organization. People in single-threaded roles, making more functional and cross-cutting teams with more experience, dealing with dependencies on those roles. The problems we are dealing with are “people problems” that are not that different from the problems we deal with in the technical world. There are different platforms, different ideas and different language that we are using but it’s honestly the same problem that we are trying to solve.

The post Practicing Agile with HR Teams appeared first on LeadingAgile.

Categories: Blogs

Pushing vs. Pulling Work in Your Agile Project

Johanna Rothman - Tue, 11/29/2016 - 18:58

If you’re thinking about agile or trying to use it, you probably started with iterations in some form. You tried (and might be still trying) to estimate what you can fit into an iteration. That’s called “pushing” work, where you commit to some number of items of work in advance.

And, if you have to service interruptions, such as support on previous projects, or support the production server, or help another project, you might find that you can’t “push” very well.  You have trouble predicting what you can do every two weeks. While the iteration duration is predictable, what you predict for the content of your iterations is not predictable.  And, if you try to have longer iterations, they are even less predictable.

On the other hand, you might try “pull” agile, where you set up a kanban board, visualize your flow of value, and see where you have capacity in your team and where you don’t. Flow doesn’t have the built-in notion of project/work cadence. On the other hand, it’s great for visualizing all the work and seeing where you have bottlenecks.

Push and PullHere’s the problem: there is No One Right Way to manage the flow of work through your team. Every team is different.

Iterations provide a cadence for replanning, demos, and retrospectives. That cadence, that project rhythm, helps to set everyone’s expectations about what a team can deliver and when.

Kanban provides the team a perspective on where the work is, and if the team measures it, the delays between stages of work. Kanban helps a team see its bottlenecks.

Here are some options you might consider:

  • Add a kanban board that visualizes your workflow before you change anything. Gather some data about what’s happening. Are your stories quite large, so you have more pressure for more deliverables? Do you have more interruptions than you have project work?
  • Reduce the iteration duration. Interruptions are a sign that you might need to change priorities. Some teams discover they can move to one-week iterations and manage the support needs.
  • Ask questions such as these for incoming non-project work: “When do you need this done? Is it more or less important or valuable than the project work?”
  • Make sure you are a cross-functional team. Teams can commit to finishing work in iterations. A group of people who are not interdependent have trouble committing to iterations.

Teams who use only iterations may not know the workflow they really have, or if they have more project or support/interrupting work. Adding an urgent queue might help everyone see the work. And, more explicit columns for analysis, dev & unit test, testing, waiting (as possibilities) in addition to the urgent queue might help the team see where they spend time.

Some teams try to work in two-week (or longer) iterations, but the organization needs more frequent change. Kanban might help visualize this, and allow the team to change what they commit to.

Some POs don’t realize they need to ask questions about value for all the work coming into a team. If the work bypasses a PO, that’s a problem. If the PO does not rank the work, that’s a problem. And, if the team can’t finish anything in a one-week iteration, that’s a sign of interdependencies or stories that are too large for a team. (There might be other problems. Those are the symptoms I see most often.

You can add a kanban board inside your iteration approach to agile. You might consider moving to flow entirely with specific dates for project cadence. For example, you might say, “We do demos every month on the 5th and the 19th of the month.” That would provide a cadence for your project.

You have choices about pushing work or pulling work (or both) for your project. Consider which will provide you most value.

P.S. If you or your PO has trouble making smaller stories, consider my workshop, Practical Product Ownership.

Categories: Blogs

The Core Principles of Agile

I recently watched a video titled, "Why Is Modern Art So Bad?"

One of points of the video was that for centuries, art improved because artists demanded of themselves that they meet the highest standards of excellence.

The video claimed that this aspiration in art was eventually pushed out by the claim that "beauty is in the eye of the beholder." All art then became personal expression and essentially anything could be art.

And we've probably all been to museums and seen--or at least heard of--exhibits that left us wondering, "How is that art?"

Without standards of excellence in art, anything can be art.

Agile without Standards

And the same applies to agile. Without standards of excellence for agile, anyone can call anything agile.

I encounter this today in talking to companies that are agile because the boss has declared them agile. They don't deliver frequently. They don't iterate towards solutions. They don't seek continuous improvement. Teams are not empowered and self-organizing. But they must be agile because someone has slapped that label on their process.

Worse, we all see this today in heavyweight methodologies that don't resemble the agile described in the Agile Manifesto. But they must be agile because it's right there in the name of the process.

Many of us, as experienced agilists, can recognize what is truly agile when we see it. Yet agile is hard to define. It's more than just the four value statements or 12 principles of the Agile Manifesto. Or is it less than those?

What Do You Think?

What do you think are the core principles or elements of agility? Please share your thoughts in the comments below.

Categories: Blogs

Git Tutorial: Squashing Commits

About SCRUM - Hamid Shojaee Axosoft - Tue, 11/29/2016 - 16:00

Hey, Git users! Welcome to another lesson in our Git tutorial series. In this video, John, an Axosoft developer, will teach you about squashing commits. Tune in to find out:

  • What does it mean to squash a commit in Git?
  • When should you squash a commit?
Categories: Companies

All Kanban Queues Are Not the Same - Manufacturing and Software Services Are Different

NetObjectives - Tue, 11/29/2016 - 13:50
  Kanban originated at Toyota as part of the manufacturing process.  It’s been adopted to software delivery.  In both forms, there are stages of production or creation that may have queues in-between the stages.  Differences in the purpose of these queues are sometimes overlooked when describing the flow through software processes.   Along with queues, “pull” and “push” can have different...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Is Readability Truly a Code Quality

NetObjectives - Tue, 11/29/2016 - 12:09
Readability and code quality frequently coincide but does that mean readability is a code quality? My friends and colleagues  This is an important distinction because quality problems in code demand changes to that code.  Smells, on the other hand, merely require investigation. A lot of bad code is effectively impossible to read, except possibly by its original author.  Is that enough to make...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Halloween's MVP

Here's the 2016 Pumpkin decorating contest loser.  It's been a real LEAN year for the Scrum team.
Have you heard of a MVP - Minimal Viable Pumpkin?

Minimal Viable Pumpkin (MVP)
Categories: Blogs

What I’ve Been Writing Lately

Johanna Rothman - Tue, 11/29/2016 - 00:00

You might have noticed I have not written as much in this blog for the past couple of months as I normally do. That’s because I’ve been involved in another writing project that’s taken a ton of my time.

I’m part of the writing team for the Agile Practice Guide. The Guide is a joint venture between the Agile Alliance and the PMI. See Bridging Mindsets: Creating the Agile Practice Guide.

We work in timeboxes, iterating and incrementing over the topics in the guide. We sometimes pair-write, although we more often write and review each other’s work as a pair.

If you would like to review the guide as a subject matter expert, send me an email. You’ll have about a month to review the guide, starting in approximately January 2017. I am not sure of the dates yet, because I am not sure if we will finish all our writing when we originally thought. Yes, our project has risks!

Categories: Blogs

Back to Basic: User Stories and Acceptance Criteria

Every new user story presented to the team for development, must be accompanied with a set of user acceptance criteria which can drive development and testing. ——————– Acceptance criteria is a great tool to ensure that the product being developed is actually what the Product Owner wants. Every user story is accompanied by a set of […]
Categories: Blogs

Targetprocess v.3.10.5: Lane suggestions and bug fixing

TargetProcess - Edge of Chaos Blog - Mon, 11/28/2016 - 23:01
Changes to Reports

We’ve changed the list of predefined and custom reports that could previously be found in the ‘Other Reports’ top menu. The old predefined reports from Targetprocess 2 have had their day and have now given way to the new Visual Reports Editor.

For example: to create a brand new 'Time by Person' chart, go to the 'Create' option at the bottom of the page, select Report, and then find the 'Time Spent' templates for your new report.


Custom reports are now called 'Tabular Reports.' You can still find them in their usual place: in the Reports menu in the top bar:

Tabular Reports

Lane suggestions in Board setup

The most appropriate options will now be displayed first when selecting fields for lanes in Board setup. This improvement applies to cards that have a large amount of options available for lanes, i.e. Epics, Features, User Stories, Tasks, Bugs, Requests, Test Plans, and Test Plan Runs.


Bug Fixes
  • Test Run Import plugin: Test Plan selector will now be able to show more than 1000 entities at a time
  • Text comments without line breaks will no longer truncate instead of moving into new line
  • Fixed multiple script errors on a Timesheet if Time entity has a Targetprocess entity custom field setup
  • Deleted or missing attachments will not prevent entity removal
  • Bugzilla Integration: fixed a synchronization failure for some old profiles
  • Fixed an internal server error in the Audit History of a program if custom field changes took place
Categories: Companies

Technical Dependency Communication in Scaling Agile

Scrum Expert - Mon, 11/28/2016 - 17:43
Developing large software systems automatically generate some technical dependency issues. If this is often managed by software architects in traditional projects, how do you communicate this technical dependencies when you are organized using an Agile approach? This is the topic discussed in the paper written by a Swedish research group. As Agile approaches are increasingly adopted by large software development organizations with distributed teams, the Agile breakdown of complex tasks create large challenges due to the technical dependencies between teams. This is not new, but with Agile the technical dependencies do not become more or less, they just become more obvious and this is actually a possibility for practice to deal with them. The research paper tried to answer two main questions based on a case study: * What are the challenges associated with technical dependencies between teams in a large-scale agile software development? * What affects the likelihood of a challenge to occur? The following technical dependencies are considered: * Unpredictability: teams find difficult to know beforehand what changes, issues, surprises, failures and successes they will come across during the development of a feature. * Conflicting priorities: a team might depend on a component that has lower priority in the backlog of another team. * Difficulty to understand overlapping and short release cycles when teams are constantly changing priorities in each sprint To mitigate the challenges created by these technical dependencies, the authors wrote that “one has to start with mitigating one challenge and then continue to exploit the [...]
Categories: Communities

Accelerate your Scrum with patterns

Leading Agile - Mon, 11/28/2016 - 15:02

A design pattern is a re-usable form of a solution to a design problem, given a context. The idea was introduced by the architect Christopher Alexander [1] and has been adapted for various other disciplines, most notably computer science and software development. If you come from the development side of the house, you should be familiar with patterns. Back in the 90’s a bunch of really smart dudes known as the Gang of Four (GoF), inspired by Alexander, published one of the all-time great software engineering books “Design Patterns – Elements of Reusable Object-Oriented Software”. This book ignited the concept of design patterns in software development. Authored by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, it has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages.

Scrum patterns, like design patterns, are proven solutions to repeatable problems, given a particular context.

In similar vein, many of those pattern practitioners from the glory days of OO like James Coplien, Jeff Sutherland, etc. decided to form a Scrum Patterns group known as ScrumPLoP to do for the Scrum industry what the GoF did for software engineering. Their mission, also inspired by Alexander, is to build a body of pattern literature which captures the successful practices of Scrum. Scrum is a context-sensitive framework. It doesn’t tell you what to do. It is not a method. Rather it provides a scaffold to explore and try many different techniques, including the application of patterns. Scrum patterns, like design patterns, are proven solutions to repeatable problems, given a particular context. ScrumPLoP ( is the resource for the library of Scrum patterns. There on the home page you will find a quick synopsis of a few of the more popular and useful patterns, authored by Jeff Sutherland – Stable Team, Yesterday’s Weather, Daily Clean Code, Scrumming the Scrum, etc.

[1] Alexander, Christopher (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press. ISBN 0-19-501919-9.

The post Accelerate your Scrum with patterns appeared first on LeadingAgile.

Categories: Blogs

A look at Six Years of Blogging Stats

What do you get from six years of blogging about Agile/Scrum and your continued learning experiences?

Stats from Agile Complexification Inverter blog site

Well the stats are just one insignificant measure of what one gets from writing about their experience.

The bad artist imitate, the great artist steal.The more meaningful measures have been seeing some of these articles and resources put into practice by other colleagues, discussion that have happened (off line & sometimes in comments or twitter, etc.) with readers that require me to refine my thinking and messaging of my thinking.  Interestingly some times seeing a resource that you have created being "borrowed" and used in another persons or companies artifact without attribution is both rewarding and a bit infuriating.  I like that the concept has resonated well with someone else and they have gone to the trouble of borrowing the concept, and repeating or improving or repurposing the concept.

Let me borrow someone else's concept:  "The Bad Artist Imitate, the GREAT Artists Steal." -- Banksy

Most of all the collection of articles are a repository of resources that I do not need to carry around in my 3-4 lbs of white & grey matter.  I can off-load the storage of concepts, research pointers and questions to a semi-perminate storage.  This is a great benefit.

Categories: Blogs

Q: What is an Agile Transition Guide?

David Koontz guiding a canoeI was at the Dallas Tech Fest last week and was asked several times what an Agile Transition Guide was (it was a title on my name tag)... it's surprising to me how many people assume they know what an Agile Coach is, yet there is no good definition or professional organization (with a possible exception coming: Agile Coaching Institute).

So naturally the conversation went something like this:

Inquisitive person:  "Hi David, what's an Agile Transition Guide?  Is that like a coach?"

David:  "Hi, glad you asked.  What does a coach do in your experience?"

Inquisitive person: "They help people and teams improve their software practices."

David:  "Yes, I do that also."

Inquisitive person: "Oh, well then why don't you call yourself a coach?"

David:  "Great question:  Let's see...  well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching.  So do you see why I don't call myself a coach?"

Inquisitive person: "Well no, not really.  That's just semantics.  So you're not a coach... OK, but what's is a guide?"

David:  "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide?  What do they do differently than a coach?  Did you get to choose your guide, or were they assigned to your group?"

Inquisitive person: "Oh, yeah.  I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own.  They also had some great gear and lots of local knowledge of where to find the trout."

David:  "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."

Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"

David:  "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting.  Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide.  A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."

Richard FeynmanAnd now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding.  See Richard Feynman's dialogue about "Why questions"

So, I'm not a Coach

I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching).  This relationship was typically dysfunctional from the standpoint of being a coach.  So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching.  It intends the relationship to be vastly different.  Since I'm very techie, I appreciate using the correct words, and phrase for a concept.  (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things.  Two Hard Things)

So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching.  Then I needed a new term.  And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role.  Therefore I coin the term Agile Transformation Guide.  But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset.  So a transition guide is more generic, capable of the situational awareness of the desire of the organization.

See Also:

Six Kinds of Agile Coaches by Ravi Verma Describes the HUGeB coach, the one to be.
Where Agile goes to Die - Dave Nicolette - about those companies that are late adopters or laggards in the innovation curve and the challenges that "coaches" have when engaging with them.
The Difference Between Coaching & Mentoring

Scrum Master vs Scrum Coach by Charles Bradley

Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.

Academic paper:  Coaching in an Agile Context by David Koontz

What is the ROI of Agile Coaching - Payton Consulting

Interesting Twitter conversation about the nature of "coaching" with Agile42 group.

Categories: Blogs

Welcome to Kagibox, our first physical product!

IceScrum - Fri, 11/25/2016 - 15:33
Today’s topic is quite different from what we usually talk about here. No version of iceScrum or new feature for your favorite tool (don’t worry you will get some very soon), but a presentation of a brand new product we just launched this week: Kagibox! For a long time, our team has been thinking of…
Categories: Blogs

1st Conference, Melbourne, Australia, March 2-3 2017

Scrum Expert - Thu, 11/24/2016 - 08:00
The 1st Conference is a two-day event aimed at people starting out with Agile and Scrum run by practitioners of the Agile Melbourne community. The format of the 1st Conference is a one day of presentation and one day of workshops presented by Australian and overseas Agile experts. In the agenda of the 1st Conference you can find topics like ” Heart of Agile”, “Is there a future for business analysis?”, “Influence and inspire with stories”, “Goals on Every Level”, “Recruiting for Agile or Agility”, “Effective Agile Leadership: A practical model for Agile Managers”, “Road Mapping your way to Agile Fluency”, “The first 18 months of our Agile transformation”, “Infrastructure for Agile teams”, “Agile Governance”, “Large Scale Agile – LESS”, “Large Scale Agile – SAFe”, “The heart of Scrum”, “What is Kanban”. Web site: Location for the 1st Conference: RMIT University Storey Hall, Building 16, 336–348 Swanston St, Melbourne VIC 3000, Australia
Categories: Communities

Iterations and Increments

Johanna Rothman - Wed, 11/23/2016 - 18:07

general-agile-picture-copyright-1024x645Agile is iterative and incremental development and frequent delivery with cultural change for transparency.

What do the words iterative and incremental mean?

Iterative means we take a one-piece-at-a-time for creating an entire feature. Iterative approaches manage the technical risk. We learn about the risk as we iterate through the entire feature set.

Incremental means we deliver those pieces of value. Incremental approaches manage the schedule risk, because we deliver finished work.

Agile works because we manage both technical and schedule risk. We iterate over a feature set, delivering chunks of value. (One reason to deliver value often is so we can change what the team does next.)

Here’s a way to think about this if I use a feature set called “secure login.” Now, no one wants to log in. But, people want to have security for payment. So secure login might be a way to get to secure payment. The theme, or what I have been calling a feature set, is “Secure login.” A feature set is several related features that deliver a theme.

If you want to iterate on the feature set, you might deliver these valuable increments (I first wrote about this in How to Use Continuous Planning):

  1. Already existing user can log in.
  2. Users can change their password.
  3. Add new user as a user.
  4. Add new user as admin.
  5. Prevent unwanted users from logging in: bots, certain IP addresses, or a physical location. (This is three separate stories.)

If you implement the first story, you can use a flat file. You can still use a flat file for the second story. Once you start to add more than 10 users, you might want to move to some sort of database. That would be a story. It’s not “Create a database.” The story is “Explore options for how to add 10, 100, 1000, 10000 users to our site so we can see what the performance and reliability implications are.”

Notice the explore as part of the story. That would lead to a spike to generate options that the team can discuss with the PO. Some options have performance implications.

Every time the team iterates over the feature set, they deliver an increment. Since many teams use timeboxes, they use “iterations” as the timebox. (If you use Scrum, you use sprints.) Notice the term “iterate over the feature set.”

In incremental life cycles, such as staged delivery, the team would finish all the features in the one feature set. Incremental life cycles did not necessarily use timeboxes to timebox the incremental development. In iterative life cycles, such as spiral or RUP, the team would develop prototypes of features, or even partially finish features, but the final integration and test occurs after all the iterative development was done.

In agile, we iterate over a feature set, delivering incremental value. If you don’t finish your stories, you’re in an iterative life cycle. If you don’t limit the features you finish and finish “all” of them, you are in an incremental life cycle.

There is No One Right Way to select a life cycle for your project. If you want to use agile, you iterate over a feature set in a short time, delivering chunks of value.

If you are having trouble slicing your stories so you can create feature sets, see my Product Owner Workshop (starting in January). Super early bird expires this coming Friday.

Categories: Blogs

Acceptance Test-Driven Development: A Quick Introduction

NetObjectives - Wed, 11/23/2016 - 16:05
Acceptance Test-Driven Development: A Quick Introduction Ken Pugh and Jim Trott talk about ATDD: who is involved and who leads the effort, what is involved in writing acceptance tests, how ATDD compares with regular "analysis" you have done in the past, how ATDD compares with TDD, and the language of Acceptance Tests. Ken describes why he is so passionate about ATDD and the tangible benefits he...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.