Skip to content

Companies

Lean and Kanban at Scale

Al Shalloway, CEO of Net Objectives, discusses how to apply Lean and Kanban at scale to manage software initiatives more effectively. About this Webinar The essence of Kanban is to manage the workflow of value added activities by limiting how much work is being done. Al uses Lean thinking to extend Kanban to the portfolio, program, […]

The post Lean and Kanban at Scale appeared first on Blog | LeanKit.

Categories: Companies

Product Ownership – Dealing with capacity and prioritisation

Growing Agile - Fri, 09/05/2014 - 09:03

Last night we did a talk for SUGSA (the Scrum User Group of South Africa). It was a blast and full of eager learners icon smile Product Ownership   Dealing with capacity and prioritisation

We spoke about 2 techniques – one to talk and understand capacity and one to assist with prioritisation. The slides are on slideshare.

And you can read about the techniques, The Freeway Analogy and Prioritise your Backlog. This post might also help: A Handy Guide for Coaching Product Owners.

If you are keen to read about more of these workshops, please buy our books!

BookAR 300x300 Product Ownership   Dealing with capacity and prioritisationBookMB 300x300 Product Ownership   Dealing with capacity and prioritisationBookRP 300x300 Product Ownership   Dealing with capacity and prioritisation

 Here is a writeup from the committee: http://sugsa.org.za/2014/09/event-report-product-owners-dealing-with-capacity-and-prioritisation/.

Categories: Companies

LeanKanban Kanban Foundation Curriculum

As part of our continuing sneak peak of the new LeanKanban Modern Management Framework, I want to show how we are using it to define and communicate the curriculum for individual training classes. We are now offering a wide range of training classes at different levels. Here we look at the 2-day Kanban Foundation level training...

read more

Categories: Companies

Welcome to the Swift Playground

Xebia Blog - Thu, 09/04/2014 - 20:16

Imagine... You're working in swift code and you need to explain something to a co-worker. Easiest would be to just explain it and show the code right. So you grab your trusty editor and type some markdown.

let it = "be awesome"

Great!

So now you have a file filled with content:
swift-markdown

But it would be better if it looked like:

playground

Well you can and it's super simple, all you need is some Markdown and:

npm install -g swift-playground-builder

After that it's a matter of running:

playground my-super-nice-markdown-with-swift-code.md

Enjoy!

More info: https://github.com/jas/swift-playground-builder

Categories: Companies

Project Management with Kanban (Part 4) - Risk Review

This is my final blog post in the series on project management with Kanban. If you haven't seen the previous three posts read them here, Part 1, Part 2, Part 3. This post looks at how project managers can help with risk management and controlling the average lead time and the the lead time distribution. This is important to insure that the forecasts described in Part 3 remain trustworthy and accurate through the duration of the project. The Blocker Clustering technique described in this post was developed by Klaus Leopold and can be used to drive process improvement as well as managing project risk. You can read his original blog post, Blocker Clusters.

read more

Categories: Companies

7 Things I Validated in My First Month With VersionOne

Agile Management Blog - VersionOne - Thu, 09/04/2014 - 15:05

What’s your lucky number? In June, I attended the Agile West BSC/ADC conference in Las Vegas and didn’t do so well at the roulette table; however, two months later on 7/21/14 (lucky 7s) I placed an even bigger bet; not on red, but on Pantone Color Number 216. It’s the signature color of VersionOne, the all-in-one agile project management tool and services provider.

After almost seven years of building up my agile acumen at Cars.com, I decided that it was time to close that season of my career, and I began researching and planning my next career challenge. I outlined three key pillars that were very important to me and my ability to truly enjoy going to work every day:

  • Customer Centric Vision – Having the ability to know WHY what we do matters to customers, and matching values and alignment to priorities.
  • Clear Agile Direction – Finding a company who is moving the agile ball further down the line.
  • Fun and Innovative Culture – Life is too short and if you are going to work hard, it makes it much easier to find the joy in your job if you have fun doing it.

These were the most important traits I was seeking in part because they were the things that made me love being at Cars.com. I plugged into my network, had some interviews (and one offer that didn’t work out), and continued my quest to not settle until I found a career that valued these same traits. Then, just when I thought that finding my career “Match.com” was out of reach, I found an opening for a Chicago-based Product Speversiononecialist that turned out to be the perfect blend of vision, direction and fun.

Luckily for me, it was also at a place I knew very well, VersionOne. After a few interviews and a relatively painless courtship, I accepted the position and can report that so far it has been a jackpot payoff.

Since my start at VersionOne, I have validated or learned seven key things that I believe you can also learn from, no matter where you work:

  1. The customer is king (or queen); however, not everyone is a customer – If the slipper doesn’t fit, you can’t force it!
  2. Community is very important – Sometimes a company does things because it’s for the greater good.
  3. You can’t fake culture – If you’ve got a great culture, you’ve got it. Hang onto it.
  4. Agile is a mindset, not a methodology – Like culture, the question is not “Are you Agile?” but rather, “How Agile are you?” If you aren’t sure, take this Agile Development Quiz.
  5. Cold beer, anyone? A cold beverage and a game of pool after work is still a great way to end the day. When they say “Work Hard, Play Hard,” believe them!
  6. Valuable training is essential – Among the many other benefits, new-hire training as a group bonds people together and to the company.
  7. VersionOne is a great place to be because of the people, agile project management products and services to help companies achieve agile success, as well as VersionOne’s commitment to the agile community at large.

Going into my Product Specialist position I tried hard to find red flags, indicators that would give me some warning or reason to pause. At the end of the day, every flag I saw was Pantone 216. It’s my new lucky number!

I hope you find your lucky number, whether it’s a career at VersionOne, a business engagement with us, or something totally unrelated!

Read more on my personal blog at a12p.blogspot.com.

 

Categories: Companies

Webinar: DevOps for Agility

Rally Agile Blog - Thu, 09/04/2014 - 13:00

Today’s fast-moving markets expose threats and opportunities at every turn. Whether you’re a large enterprise or a small startup, it’s no longer enough to simply practice Agile development. To survive — and thrive — in this disruptive environment, you need agility throughout your organization.

Join Rally and Chef for a webinar about the role of DevOps in building agility and responsiveness. Learn more about how Rally practices continuous deployment, accelerates application development, and tightens customer feedback loops. Hear how you can institutionalize DevOps and use Chef to support a speed-focused approach. 

          

DATE: Thursday, September 4

TIME: 11:00 AM Pacific / 2:00 PM Eastern

PARTICIPANTS: 

  • Jonathan Chauncey, developer at Rally Software
  • Jeff Smith, development manager at Rally Software
  • Colin Campbell, director of patterns and practices at Chef
  • [moderator] Alan Shimel, editor-in-chief, DevOps.com

Register here: http://devops.megameeting.com/registration/?id=1949-232488

Rally Software
Categories: Companies

Scaling Agile with New SAFe Templates

Since day one, LeanKit has been dedicated to helping organizations scale Lean and Agile practices across the enterprise. Discover how LeanKit is simplifying the adoption of the Scaled Agile Framework® (SAFe) with new portfolio, program, and team level board templates. Implementing SAFe with LeanKit Lean thinking is foundational to SAFe — making LeanKit uniquely suited to support […]

The post Scaling Agile with New SAFe Templates appeared first on Blog | LeanKit.

Categories: Companies

React in modern web applications: Part 1

Xebia Blog - Tue, 09/02/2014 - 13:00

At Xebia we love to share knowledge! One of the ways we do this is by organizing 1-day courses during the summer. Together with Frank Visser we decided to do a training about full stack development with Node.js, AngularJS and Facebook's React. The goal of the training was to show the students how one could create a simple timesheet application. This application would use nothing but modern Javascript technologies while also teaching them best practices with regards to setting up and maintaining it.

To further share the knowledge gained during the creation of this training we'll be releasing several blog posts. In this first part we'll talk about why to use React, what React is and how you can incorporate it into your Grunt lifecycle.

This series of blog posts assume that you're familiar with the Node.js platform and the Javascript task runner Grunt.

What is React?

ReactJS logo

React is a Javascript library for creating user interfaces made by Facebook. It is their answer to the V in MVC. As it only takes care of the user interface part of a web application React can be (and most often will be) combined with other frameworks (e.g. AngularJS, Backbone.js, ...) for handling the MC part.

In case you're unfamiliar with the MVC architecture, it stands for model-view-controller and it is an architectural pattern for dividing your software into 3 parts with the goal of separating the internal representation of data from the representation shown to the actual user of the software.

Why use React?

There are quite a lot of Javascript MVC frameworks which also allow you to model your views. What are the benefits of using React instead of for example AngularJS?

What sets React apart from other Javascript MVC frameworks like AngularJS is the way React handles UI updates. To dynamically update a web UI you have to apply DOM updates whenever data in your UI changes. These DOM updates, compared to reading data from the DOM, are expensive operations which can drastically slow down your application's responsiveness if you do not minimize the amount of updates you do. React took a clever approach to minimizing the amount of DOM updates by using a virtual DOM (or shadow DOM) diff.

In contrast to the normal DOM consisting of nodes the virtual DOM consists of lightweight Javascript objects that represent your different React components. This representation is used to determine the minimum amount of steps required to go from the previous render to the next render. By using an observable to check if the state has changed React prevents unnecessary re-renders. By calling the setState method you mark a component 'dirty' which essentially tells React to update the UI for this component. When setState is called the component rebuilds the virtual DOM for all its children. React will then compare this to the current virtual sub-tree for the same component to determine the changes and thus find the minimum amount of data to update.

Besides efficient updates of only sub-trees, React batches these virtual DOM batches into real DOM updates. At the end of the React event loop, React will look up all components marked as dirty and re-render them.

How does React compare to AngularJS?

It is important to note that you can perfectly mix the usage of React with other frameworks like AngularJS for creating user interfaces. You can of course also decide to only use React for the UI and keep using AngularJS for the M and C in MVC.

In our opinion, using React for simple components does not give you an advantage over using AngularJS. We believe the true strength of React lies in demanding components that re-render a lot. React tends to really outperform AngularJS (and a lot of other frameworks) when it comes to UI elements that require a lot of re-rendering. This is due to how React handles UI updates internally as explained above.

JSX

JSX is a Javascript XML syntax transform recommended for use with React. It is a statically-typed object-oriented programming language designed for modern browsers. It is faster, safer and easier to use than Javascript itself. Although JSX and React are independent technologies, JSX was built with React in mind. React works without JSX out of the box but they do recommend using it. Some of the many reasons for using JSX:

  • It's easier to visualize the structure of the DOM
  • Designers are more comfortable making changes
  • It's familiar for those who have used MXML or XAML

If you decide to go for JSX you will have to compile the JSX to Javascript before running your application. Later on in this article I'll show you how you can automate this using a Grunt task. Besides Grunt there are a lot of other build tools that can compile JSX. To name a few, there are plugins for Gulp, Broccoli or Mimosa.

An example JSX file for creating a simple link looks as follows:

/** @jsx React.DOM */
var link = React.DOM.a({href: 'http://facebook.github.io/react'}, 'React');

Make sure to never forget the starting comment or your JSX file will not be processed by React.

Components

With React you can construct UI views using multiple, reusable components. You can separate the different concepts of your application by creating modular components and thus get the same benefits when using functions and classes. You should strive to break down the different common elements in your UI into reusable components that will allow you to reduce boilerplate and keep it DRY.

You can construct component classes by calling React.createClass() and each component has a well-defined interface and can contain state (in the form of props) specific to that component. A component can have ownership over other components and in React, the owner of a component is the one setting the props of that component. An owner, or parent component can access its children by calling this.props.children.

Using React you could create a hello world application as follows:

/** @jsx React.DOM */
var HelloWorld = React.createClass({
  render: function() {
    return <div>Hello world!</div>;
  }
});

Creating a component does not mean it will get rendered automatically. You have to define where you would like to render your different components using React.renderComponent as follows:

React.renderComponent(<HelloWorld />, targetNode);

By using for example document.getElementById or a jQuery selector you target the DOM node where you would like React to render your component and you pass it on as the targetNode parameter.

Automating JSX compilation in Grunt

To automate the compilation of JSX files you will need to install the grunt-react package using Node.js' npm installer:

npm install grunt-react --save-dev

After installing the package you have to add a bit of configuration to your Gruntfile.js so that the task knows where your JSX source files are located and where and with what extension you would like to store the compiled Javascript files.

react: {
  dynamic_mappings: {
    files: [
      {
        expand: true,
        src: ['scripts/jsx/*.jsx'],
        dest: 'app/build_jsx/',
        ext: '.js'
      }
    ]
  }
}

To speed up development you can also configure the grunt-contrib-watch package to keep an eye on JSX files. Watching for JSX files will allow you to run the grunt-react task whenever you change a JSX file resulting in continuous compilation of JSX files while you develop your application. You simply specify the type of files to watch for and the task that you would like to run when one of these files changes:

watch: {
  jsx: {
    files: ['scripts/jsx/*.jsx'],
    tasks: ['react']
  }
}

Last but not least you will want to add the grunt-react task to one or more of your grunt lifecycle tasks. In our setup we added it to the serve and build tasks.

grunt.registerTask('serve', function (target) {
  if (target === 'dist') {
    return grunt.task.run(['build', 'connect:dist:keepalive']);
  }

  grunt.task.run([
    'clean:server',
    'bowerInstall',
    <strong>'react',</strong>
    'concurrent:server',
    'autoprefixer',
    'configureProxies:server',
    'connect:livereload',
    'watch'
  ]);
});

grunt.registerTask('build', [
  'clean:dist',
  'bowerInstall',
  'useminPrepare',
  'concurrent:dist',
  'autoprefixer',
  'concat',
  <strong>'react',</strong>
  'ngmin',
  'copy:dist',
  'cdnify',
  'cssmin',
  'uglify',
  'rev',
  'usemin',
  'htmlmin'
]);
Conclusion

Due to React's different approach on handling UI changes it is highly efficient at re-rendering UI components. Besides that it's easily configurable and integrate in your build lifecycle.

What's next?

In the next article we'll be discussing how you can use React together with AngularJS, how to deal with state in your components and how to avoid passing through your entire component hierarchy using callbacks when updating state.

Categories: Companies

Retrospective plan for a new scrum team

Growing Agile - Mon, 09/01/2014 - 10:00

We feel it is important for teams new to Scrum to get value from their retrospectives right from the beginning. With new teams we usually facilitate the first retrospective with the ScrumMasters observing. We share our retro plan with them in advance so they can follow what we are doing.

Here is a simple retrospective plan following the 5 steps for a team new to Scrum. We made sure to keep the focus positive and introduce basic techniques like brainstorming, clustering and dot voting that the teams are likely to use again and again. Since the team is new all the techniques need to be explained. We also made sure that the team picked an action that was within their own control, since many new Scrum teams believe that things outside the team need to change, and don’t realise how much they can change themselves.

 Retrospective plan for a new scrum team  Retrospective plan for a new scrum team

Categories: Companies

Learning about Risk & WIP from Real Life

I find that real life examples can help people understand why you can't talk about kanban systems without talking about risk, and why you can't calculate WIP limits without understanding work item types, risk and classes of service. Consider the humble problem of "how many shirts do you need hanging in your closet?"...

read more

Categories: Companies

Sneak Peak at Modern Management Framework

Image: 

In China, "Kanban" simply means "looking at the board." For a Chinese audience, Kanban is encapsulated in the cartoon on the cover of my Kanban: Successful Evolutionary Change for your Technology Business. They don't need to look further than the characters standing in front of the board. Hence, to a Chinese mind, our management approach is centered around a standup meeting. All well and good and why not?

However, a senior executive at one of our clilents felt that this perception was likely to undermine the true value and the potential impact of our teachings on his business. So he suggested that we give the wider collection of ideas, intellectual property and teaching tools, a different name. It so happens I'd been thinking along similar lines and introducing terms and branding in our business to lay the foundation for this. So here it is, "The Modern Management Framework." This isn't new. It's the collection of our existing class curriculum and consulting tools but presented altogether in one place for the first time and under one banner.

read more

Categories: Companies

This is Way Better Than the Ice Bucket Challenge!

Agile Management Blog - VersionOne - Thu, 08/28/2014 - 22:16

If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.

But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.

I posed this question:

What’s the Best Way to Spend 10 Minutes?

Let’s think about this for a minute…

You could:

  • Ice-bucket challenge someone
  • Set a stapler in a Jell-o moldStapler
  • Crash someone’s Facebook by inviting them to Candy Crush
  • Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
  • Load a DVORAK driver onto a PC with a normal keyboard
  • Clean those 24 sticky coffee rings off your desk
  • Assign a bunch of fake stories to people

But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.

Why?

2014_SOA_banner_300x250

“The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”

- SD Times Editor-in-Chief David Rubinstein

Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.

If you take it, you get:

  • Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
  • Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
  • Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes

What are you waiting for? Take the State of Agile survey now.

take survey now image

 

Categories: Companies

Lean Startup Metrics and Analytics to Support Innovation and Learning in the Enterprise

BigVisible Solutions :: An Agile Company - Thu, 08/28/2014 - 22:04

At BigVisible we’ve been helping companies improve the way they work; HOW they produce technology products for well over a decade. We’ve seen amazing improvements in organizations’ ability to release quickly, accelerate time to market, improve quality, and engage in faster feedback cycles for better products and less waste. As your delivery capability becomes more […]

The post Lean Startup Metrics and Analytics to Support Innovation and Learning in the Enterprise appeared first on BigVisible Solutions.

Categories: Companies

Filter Enhancements for an Even Clearer View

Do you know which cards are stuck and require attention, what’s due within the next week/month/quarter, or what cards are assigned to you? These are just a few of questions that can be answered with LeanKit’s advanced filter functionality. Upcoming filter enhancements will make it even easier for you to get a focused view of […]

The post Filter Enhancements for an Even Clearer View appeared first on Blog | LeanKit.

Categories: Companies

Improving Software Development at Scale: Promise and Pitfalls

Improving projects with xProcess - Thu, 08/28/2014 - 16:42




Here's my talk from the London Lean Kanban Day 2014. Enjoy!
Categories: Companies

CocoaHeadsNL @ Xebia on September 16th

Xebia Blog - Thu, 08/28/2014 - 12:20

On Tuesday the 16th the Dutch CocoaHeads will be visiting us. It promises to be a great night for anybody doing iOS or OSX development. The night starts at 17:00, diner at 18:00.

If you are an iOS/OSX developer and like to meet fellow developers? Come join the CocoaHeads on september 16th at our office. More details are on the CocoaHeadsNL meetup page.

Categories: Companies

What should a new ScrumMaster be doing?

Growing Agile - Thu, 08/28/2014 - 09:59

We are coaching at a new client, helping them transition to Scrum. As a result we have a group of totally new ScrumMasters. Any new role with new responsibilities is a challenge. As an experienced ScrumMaster there are many lists of what you should be doing all day everyday. But if you’re brand new and so is you team – it’s a bit like the blind leading the blind.

Our particular challenge was that none of our new ScrumMasters could understand how this could possibly be a full time role. They have 1 team each.

The first exercise we did was to ask them to write down all the impediments they had noticed in the first 2 weeks. Anything that they thought had slowed their team down. Anything they think might become a problem. Anything they had heard others say. We gave them 5 minutes in silence to make notes and then went around having each explain.

WOW! This worked so well! They had noticed a lot of impediments and potential problems. And they were big, hairy, scary ones. Next we asked – so if your job is to ensure impediments are removed, and we look at this list … do any of you still think this is a part time role? A few chuckles and looks of surprise, the exercise helped open their minds to the scope of the role.

We didn’t want to totally overwhelm them though – so we came up with the mindmap below of what they need to do in the first few sprints. If you can think of some others – please leave a comment for us icon smile What should a new ScrumMaster be doing?
NewSMMindmap e1409212627911 1024x684 What should a new ScrumMaster be doing?

Categories: Companies

What is your next step in Continuous Delivery? Part 1

Xebia Blog - Wed, 08/27/2014 - 22:15

Continuous Delivery helps you deliver software faster, with better quality and at lower cost. Who doesn't want to delivery software faster, better and cheaper? I certainly want that!

No matter how good you are at Continuous Delivery, you can always do one step better. Even if you are as good as Google or Facebook, you can still do one step better. Myself included, I can do one step better.

But also if you are just getting started with Continuous Delivery, there is a feasible step to take you forward.

In this series, I describe a plan that helps you determine where you are right now and what your next step should be. To be complete, I'll start at the very beginning. I expect most of you have passed the first steps already.

The steps you already took

This is the first part in the series: What is your next step in Continuous Delivery? I'll start with three steps combined in a single post. This is because the great majority of you has gone through these steps already.

Step 0: Your very first lines of code

Do you remember the very first lines of code you wrote? Perhaps as a student or maybe before that as a teenager? Did you use version control? Did you bring it to a test environment before going to production? I know I did not.

None of us was born with an innate skills for delivering software in a certain way. However, many of us are taught a certain way of delivering software that still is a long way from Continuous Delivery.

Step 1: Version control

At some point during your study of career, you have been introduced to Version Control. I remember starting with CVS, migrating to Subversion and I am currently using Git. Each of these systems are an improvement over te previous one.

It is common to store the source code for your software in version control. Do you already have definitions or scripts for your infrastructure in version control? And for your automated acceptance tests or database schemas? In later steps, we'll get back to that.

Step 2: Release process

Your current release process may be far from Continuous Delivery. Despite appearances, your current release process is a useful step towards Continuous Delivery.

Even if you delivery to production less than twice a year, you are better off than a company that delivers their code unpredictably, untested and unmanaged. Or worse, a company that edits their code directly on a production machine.

In your delivery process, you have planning, control, a production-like testing environment, actual testing and maintenance after the go-live. The main difference with Continuous Delivery is the frequency and the amount of software that is released at the same time.

So yes, a release process is a productive step towards Continuous Delivery. Now let's see if we can optimize beyond this manual release process.

Step 3: Scripts

Imagine you have issues on your production server... Who do you go to for help? Do you have someone in mind?

Let me guess, you are thinking about a middle-aged guy who has been working at your organisation for 10+ years. Even if your organization is only 3 years old, I bet he's been working there for more than 10 years. Or at least, it seems like it.

My next guess is that this guy wrote some scripts to automate recurring tasks and make his life easier. Am I right?

These scripts are an important step towards Continuous Delivery. in fact, Continuous Delivery is all about automating repetitive tasks. The only thing that falls short is that these scripts are a one-man-initiative. It is a good initiative, but there is no strategy behind it and a lack of management support.

If you don't have this guy working for you, then you may have a bigger step to take when continuing towards the next step of Continuous Delivery. To successfully adopt Continuous Delivery on the long run, you are going to need someone like him.

Following steps

In the next parts, we will look at the following steps towards becoming world champion delivering software:

  • Step 4: Continuous Delivery
  • Step 5: Continuous Deployment
  • Step 6: "Hands-off"
  • Step 7: High Scalability

Stay tuned for the following posts.

Categories: Companies

Synchronize the Team

Xebia Blog - Tue, 08/26/2014 - 14:52

How can you, as a scrum master, improve the chances that the scrum team has a common vision and understanding of both the user story and the solution, from the start until the end of the sprint?   

The problem

The planning session is where the team should synchronize on understanding the user story and agree on how to build the solution. But there is no real validation that all the team members are on the same page. The team tends to dive into the technical details quite fast in order to identify and size the tasks. The technical details are often discussed by only a few team members and with little or no functional or business context. Once the team leaves the session, there is no guarantee that they remain synchronized when the sprint progresses. 

The only other team synchronization ritual, prescribed by the scrum process, is the daily scrum or stand-up. In most teams the daily scrum is as short as possible, avoiding semantic discussions. I also prefer the stand-ups to be short and sweet. So how can you or the team determine that the team is (still) synchronized?

Specify the story

In the planning session, after a story is considered ready enough be to pulled into the sprint, we start analyzing the story. This is the specification part, using a technique called ‘Specification by Example’. The idea is to write testable functional specifications with actual examples. We decompose the story into specifications and define the conditions of failure and success with examples, so they can be tested. Thinking of examples makes the specification more concrete and the interpretation of the requirements more specific.

Having the whole team work out the specifications and examples, helps the team to stay focussed on the functional part of the story longer and in more detail, before shifting mindsets to the development tasks.  Writing the specifications will also help to determine wether a story is ready enough. While the sprint progresses and all the tests are green, the story should be done for the part of building the functionality.

You can use a tool like Fitnesse  or Cucumber to write testable specifications. The tests are run against the actual code, so they provide an accurate view on the progress. When all the tests pass, the team has successfully created the functionality. In addition to the scrum board and burn down charts, the functional tests provide a good and accurate view on the sprint progress.

Design the solution

Once the story has been decomposed into clear and testable specifications we start creating a design on a whiteboard. The main goal is to create a shared visible understanding of the solution, so avoid (technical) details to prevent big up-front designs and loosing the involvement of the less technical members on the team. You can use whatever format works for your team (e.g. UML), but be sure it is comprehensible by everybody on the team.

The creation of the design, as an effort by the whole team, tends to sparks discussion. In stead of relying on the consistency of non-visible mental images in the heads of team members, there is a tangible image shared with everyone.

The whiteboard design will be a good starting point for refinement as the team gains insight during the sprint. The whiteboard should always be visible and within reach of the team during the sprint. Using a whiteboard makes it easy to adapt or complement the design. You’ll notice the team standing around the whiteboard or pointing to it in discussions quite often.

The design can be easily turned into a digital artefact by creating a photo copy of it. A digital copy can be valuable to anyone wanting to learn the system in the future. The design could also be used in the sprint demo, should the audience be interested in a technical overview.

Conclusion

The team now leaves the sprint planning with a set of functional tests and a whiteboard design. The tests are useful to validate and synchronize on the functional goals. The whiteboard designs are useful to validate and synchronize on the technical goals. The shared understanding of the team is more visible and can be validated, throughout the sprint. The team has become more transparent.

It might be a good practice to have the developers write the specification, and the testers or analysts draw the designs on the board. This is to provoke more communication, by getting the people out of their comfort zone and forcing them to ask more questions.

There are more compelling reasons to implement (or not) something like specification by design or to have the team make design overviews. But it also helps the team to stay on the same page, when there are visible and testable artefacts to rely on during the sprint.

Categories: Companies