Skip to content

Feed aggregator

What’s Wrong With My Kanban Board?

TargetProcess - Edge of Chaos Blog - Thu, 04/03/2014 - 21:03

Having work visualized is the most obvious benefit of using Kanban boards for project management. Nothing else captures so well what a team is doing , as the work is retrieved from the hidden virtual closets of our minds (or, rather, databases), and externalized on a Kanban board. Especially if this board can be seen not only on a desktop computer but on a large wall-mounted screen. The more our office environment is saturated with all kinds of visual reminders, subtly incorporated in the surroundings, Kanban board being one of such reminders, the more likely we are to keep focus on our work and to perform better.


I don’t want to keep dwelling on how great Kanban is, though. I’d rather look into some of the reasons why we at times feel that something is wrong with the electronic Kanban board. Putting it in words will help see how to tune this “digital equipment” to our particular needs.

I have soo many cards on the Kanban board.. How do I make sense of all of them?

This feeling will most likely beget companies that experience rapid growth from 10 to 20 to 50 people and beyond, and need to work with more and more cards in their Kanban boards. All is fine, until your backlog and work in progress is covered by 50-70, or 100 cards at most. Having any more cards shown on a board in a snapshot would be a no-no. The clogged board space rather hinders your work, than facilitates it. What would the solution be, then?  Your Kanban board needs to be able to zoom in/out, with the ability to collapse cards in any given state, as on the screen below:

Targetprocess 3 with many cards

I need to visualize milestones. My Kanban board does not do that :(

This could be a real showstopper. While we appreciate the visual flow that Kanban provides, we are not working in car production, like Toyota. They didn’t have this need to pay attention to time. Assembly line process goes in circles. In software production, though, projects are time-sensitive in 99% cases. It’s quite rare, if not totally utopian, for a company to operate without looking at their watch. The clock is ticking, and if a Kanban board has no way of showing “what time is it?” for a project, this could be a huge source of discomfort. Ideally, we want our Kanban both to keep looking like a board and to convey the sense of time. Like that:

Targetprocess 3 timeline view

I want my Kanban board updated real-time on any screen in the world that has it open!

This is not a crazy perk. Some companies work with several distributed teams. Even teams located in one office building and in different rooms need such live updates to track their work items real-time. If you are not looking to clear a mess with some un-synced updates (hardly you are), you will want your Kanban board to show the updates like this:

I’ve covered just 3  common cases in this write-up.  Any further look into the “what’s wrongs” will depend on what you need to see, to do your work, in your company.

Look into the peephole on the right, if you want to explore how 99% of all possible Kanban “what’s wrongs” can be successfully tackled in a visual project management tool.

Related articles:

Stuck with Kanban? Consider Multiban

Our Evolution of Visual Process Management

Kanban as Multiban?

Categories: Companies

The Stages of Agile Success

Agile Game Development - Thu, 04/03/2014 - 20:02
Achieving the full benefit of agile requires a long-term commitment to change.  Applying the basic practices, such as answering three questions for 15 minutes a day, is simple, but adopting the mindset of self-organization, continuous improvement and building a culture of engagement, trust and respect is challenging.
The Three Stages of Agile AdoptionOver the past decade, I’ve witnessed common patterns of successful agile adoption and have grouped them across three stages[1] shown below, which I call the apprentice, journeyman and mastery stages.

When speaking about agile, we're talking about the agile values and principles.  How these are embodied in your day-to-day practices depends on your culture and the framework for your process.  Scrum is one such popular framework, Kanban another.  These frameworks are great scripts for starting agile, but over time teams change the practices and even blend them.  In this article, I'll mainly use Scrum terms, but your terms may vary.
ApprenticeTeams that are newly formed and/or are new to agile aren't expected to apply agile practices very well at first.  They need constant coaching as they struggle to figure out who does what and when[2].

Apprentice teams learn how to deliver features at a regular cadence and apply new roles such as Product Owner and ScrumMaster.

I prefer to see apprentice teams follow the practices, such as those of Scrum, “by the book”, because changes at the start of Scrum adoption are usually done to conceal problems Scrum exposes.

Effective Daily Stand-ups
One example of abandoning a practice too early is when teams skip the daily stand-up meeting because they feel an electronic tool is better for reporting task status.  Reporting task status is a part of the stand-up, but it is not the primary purpose and so something is lost.  The daily stand-up is meant to align a cross-discipline team to their daily priorities, revisit their commitment to their sprint goal and recommit their accountability to delivering quality features.  Thinking that it's all about task reporting is a vestige of a task-assignment culture and it takes a while to change this mindset.

Cross-Disciplined Teams
Forming cross-discipline teams that can commit to goals is critical to early adoption.  Departmental or siloed organizations will resist the formation of cross-discipline teams.  Not only do department managers fear losing control, but developers themselves will resist being teamed with those outside their own discipline.  Yet, if cross-discipline teams don't form, then the weight of dependencies and the inability to deliver a demo-able game every iteration, will prevent most of the benefits found with agile.

Well formed cross-discipline teams can take more ownership of their goals, which leads to more effective problem-solving and higher productivity.

Established Roles
Roles, such as Product Owner and ScrumMaster, are meant to balance the need to build the right features in the right order and in the right way.  The roles are separated, because they often come into conflict with one another and need to be balanced for there is a fine boundary between building features faster through improvements to productivity and building features faster by dropping quality.

Realigning existing roles with the new ones take a while to establish and even longer for the teams to understand how they are meant to function.
JourneymanWhen agile teams create a definition of done and start altering their practices to achieve it every iteration, it's a signal that they are entering the Journeyman stage.   The following areas of development maturity are common with Journeyman teams.

Leaner Designs
Through close collaboration, Journeyman teams reduce handoffs of written design documents and concept art.  For example, instead of a dozen storyboards for a level, a concept artist will draw half as many and spend more time working directly with the level artists and designers.  In this way, all disciplines can more effectively collaborate and iterate on more emergent and higher quality levels than a one-way handoff of concept art would allow.

Faster Integrations
As cross-discipline teams iterate more, the inefficiencies of practices such as branch-and-merge and hand-testing everything are replaced by practices such as continuous integration, test servers, unit testing, etc.  These practices allow more iterations on up-to-date assets and code throughout the day.  The ability to iterate more frequently contributes to higher quality.

Better Testing
As mentioned above, faster integration requires improved testing practices, such as test servers.  Additionally, Journeyman teams will increasingly integrate members of QA onto their team.  This will lead to further refinements of the definition of done.

Release Planning
As journeyman teams improve their definition of done, agile estimation techniques can be employed to produce a more reliable forecast about the schedule, cost and scope.
MasteryMastery is a stage occupied by so-called hyper-productive teams.  These teams hold themselves accountable to their results, practices and organization.  For teams to enter this stage, they must have an established level of trust within the organization and be allowed to achieve higher levels of self-organization.

100% Customization
Sometimes, when I visit a team that has been effectively inspecting and adapting agile and Scrum practices for a while, it’s hard to say “they're doing Scrum” anymore.  They completely own their work, and take much pride in it.

The goal of Scrum is to leverage the power of small, self-organizing teams to maximize the value they create.  By giving teams and individuals more freedom to make decisions about their work and providing structure, coaching and mentoring, their work becomes far more focused and meaningful.

Studio culture and structure are often barriers to this “low constraint” form of self-organization.  Fortunately, as more studios emerge that demonstrate the value of this approach, the acceptance and proof of it will continue to grow.

Continuous Improvement
Following a set of prescribed practices isn’t the goal.  The goal is continuous improvement.  Markets and technologies change.  Individuals change.  Processes have to change as well.  There are no "best practices" because the word "best" implies that there are no better.
It's Not Easy, but it's RewardingThe agile state of mind challenges our beliefs and assumption and insists that we continue to challenge them.  It flat-out defies the persistent superstition that we can treat creative people with the same tools that make machinery more productive, that we can add more people or add more hours they work or write bigger planning documents, which will result in more output.  People are far more complex.

It makes us coach, listen, challenge, inspire, care, respect, and collaborate in ways we were never trained to do.  It's a lifetime challenge with no finish line in sight.

[1] These are not unlike the three stages of martial art mastery called “ShuHaRi”
[2] This is not inherent to Scrum teams, all new teams go through a settling phase.  Google “Tuckman’s stages of group development” for more on this.

Categories: Blogs

Announcing Summer of Scrum Toronto 2014 Pre-Registration

Learn more about our Scrum and Agile training sessions on

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Agile Development Conference, Las Vegas, USA, June 1–6, 2014

Scrum Expert - Thu, 04/03/2014 - 17:51
The Agile Development Conference is an event focused on agile methods, technologies, tools, and leadership principles from thought leaders that takes place in Las Vegas. You will find at this conference inspiring keynotes, in-depth tutorials and a wide range of conference sessions. Famous Agile speakers will participate to the conference like Johanna Rothman, Ellen Gottesdiener, Janet Gregory, Pollyanna Pixton , Al Shalloway and Mitch Lacey. In the agenda up you can find topics like “The Organization Must Change Before Going Agile”, “Patterns for Effective Use Cases: Unleashing Your System’s Value”, “Essential Agile ...
Categories: Communities

Who Solves Which Problems?

Johanna Rothman - Thu, 04/03/2014 - 17:37

Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Categories: Blogs

Agile Inception: Facilitating Innovation Towards Valuable Results

Learn more about our Scrum and Agile training sessions on

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”.  Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic.  I strongly recommend this seminar as well as the book.  Another strong influence is The Inmates are Running the Asylum… by Alan Cooper.  The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix.  During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”.  I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog).  At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile.  This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis:  a shrinking market combined with shrinking market share.  The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014.  That’s half dead in some people’s books.  The clear Goal was to reverse that trend, starting with at least $11M in 2015.  They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable.  In fact, there were many, many ideas.  Too many, perhaps.  Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of.  Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal.  True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving.  Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”).  However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation.  Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”.  It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer.  The value of this investment of everyone’s time was tremendous.  The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing.  In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product.  The larger group broke into smaller groups for the subsequent discussions.  The groups worked separately and generated a the details for a few personas.  All 3 personas added value to the conversation.  The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved.  In other words, Lisa needs a story.  Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal.  Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10.  Not bad, but clearly some work still to go.  So what’s next for them?

Next steps:
  • Get the technical folks involved in the conversation (ideally, they are there from the beginning)
  • Build an increment of their solution
  • Review
  • Continue the conversation and collaboration to build shared understanding 
  • Re-gauge the confidence score
  • Iterate  
  • Repeat 
  • The likelihood of achieving the Goal increases with every iteration


Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Using AutoMapper to prevent SELECT N+1 problems

Jimmy Bogard - Thu, 04/03/2014 - 15:13

Back in my post about efficient querying with AutoMapper, LINQ and future queries, one piece I glossed over was how View Models and LINQ projection can prevent SELECT N+1 problems. In the original controller action, I had code like this:

public ActionResult Index(int? id, int? courseID)
    var viewModel = new InstructorIndexData();
    viewModel.Instructors = db.Instructors
        .Include(i => i.OfficeAssignment)
        .Include(i => i.Courses.Select(c => c.Department))
        .OrderBy(i => i.LastName);
    if (id != null)
        ViewBag.InstructorID = id.Value;
        viewModel.Courses = viewModel.Instructors.Where(
            i => i.ID == id.Value).Single().Courses;
    if (courseID != null)
        ViewBag.CourseID = courseID.Value;
        viewModel.Enrollments = viewModel.Courses.Where(
            x => x.CourseID == courseID).Single().Enrollments;
    return View(viewModel);

See that “Include” part? That’s because the view shows information from navigation and collection properties on my Instructor model:

public class Instructor : Person
    [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
    [Display(Name = "Hire Date")]
    public DateTime HireDate { get; set; }

    public virtual ICollection<CourseInstructor> Courses { get; set; }
    public virtual OfficeAssignment OfficeAssignment { get; set; }

public abstract class Person
    public int ID { get; set; }

    [Display(Name = "Last Name")]
    public string LastName { get; set; }
    [StringLength(50, ErrorMessage = "First name cannot be longer than 50 characters.")]
    [Display(Name = "First Name")]
    public string FirstMidName { get; set; }

    [Display(Name = "Full Name")]
    public string FullName
            return LastName + ", " + FirstMidName;

If I just use properties on the Instructor/Person table, only one query is needed. However, if my view happens to use other information on different tables, additional queries are needed. If I’m looping through a collection association, I could potentially have a query issued for each loop iteration. Probably not what was expected!

ORMs let us address this by eagerly fetching associations, via JOINs. In EF this can be done via the “Include” method on a LINQ query. In NHibernate, this can be done via Fetch (depending on the query API you use). This is addresses the symptom, but is not a good long-term solution.

Because our domain model exposes all data available, it’s easy to just show extra information on a view without batting an eye. However, unless we keep a database profiler open at all times, it’s not obvious to me as a developer that a given association will result in a new query. This is where AutoMapper’s LINQ projections come into play. First, we have a View Model that contains only the data we wish to show on the screen, and nothing more:

public class InstructorIndexData
    public IEnumerable<InstructorModel> Instructors { get; set; }

    public class InstructorModel
        public int ID { get; set; }

        [Display(Name = "Last Name")]
        public string LastName { get; set; }
        [Display(Name = "First Name")]
        public string FirstMidName { get; set; }

        [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
        [Display(Name = "Hire Date")]
        public DateTime HireDate { get; set; }

        public string OfficeAssignmentLocation { get; set; }

        public IEnumerable<InstructorCourseModel> Courses { get; set; } 

    public class InstructorCourseModel
        public int CourseID { get; set; }
        public string Title { get; set; }

At this point, if we used AutoMapper’s normal Map method, we could still potentially have SELECT N+1 problems. Instead, we’ll use the LINQ projection capabilities of AutoMapper :

var viewModel = new InstructorIndexData();
viewModel.Instructors = db.Instructors
    .OrderBy(i => i.LastName)

Which results in exactly one query to fetch all Instructor information, using LEFT JOINs to pull in various associations. So how does this work? The LINQ projection is quite simple – it merely looks at the destination type to build out the Select portion of a query. Here’s the equivalent LINQ query:

from i in db.Instructors
orderby i.LastName
select new InstructorIndexData.InstructorModel
    ID = i.ID,
    FirstMidName = i.FirstMidName,
    LastName = i.LastName,
    HireDate = i.HireDate,
    OfficeAssignmentLocation = i.OfficeAssignment.Location,
    Courses = i.Courses.Select(c => new InstructorIndexData.InstructorCourseModel
        CourseID = c.CourseID,
        Title = c.Title

Since Entity Framework recognizes our SELECT projection and can automatically build the JOINs based on the data we include, we don’t have to do anything to Include any navigation or collection properties in our SQL query – they’re automatically included!

With AutoMapper’s LINQ projection capabilities, we eliminate any possibility of lazy loading or SELECT N+1 problems in the future. That, I think, is awesome.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Episode #135 – Ticket Driven Agile

Integrum - Agile Weekly Podcast - Thu, 04/03/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Jake Plains discuss:

  • Ticket Driven Agile
  • Cross team collaboration
Categories: Companies

Querying An In-Memory Array Of JavaScript Objects In NodeJS

Derick Bailey - new ThoughtStream - Thu, 04/03/2014 - 13:00

I found myself wanting to query an array of in-memory objects in my NodeJS app. I know there are a ton of options out there… including the built-in filter method on arrays, underscore or lodash where methods, and more. But I really wanted something that worked like MongoDB queries. 

What I Want To Do

Given this data structure:

I wanted to write a query that looked something like this:

sift.js: How I Got What I Wanted

What I found (thanks to Joe Gornick) is sift.jsa MongoDB inspired query library for JavaScript arrays.

It’s pretty slick. It let’s me write and execute the above query, running it against my array of objects:

This returns the second object, as I expected.

Lots Of Options

From the documentation, it looks like it should work in browsers as well as nodejs environments. Of course, this all makes me wonder if MongoDB could create a portable version of their query library to use in NodeJS… but I’m liking sift so far. It does what I want, and seems small / simple enough.

I’m sure there are plenty of ways to achieve close-to this syntax with other libraries like underscore / lodash, or other JSON / JS query libraries, too. I picked sift because I like that it models after MongoDB queries. I’m already familiar with that syntax, and I’ll be able to take advantage of it as I need more complex queries.

     Related Stories 
Categories: Blogs

Physical Taskboards

Growing Agile - Thu, 04/03/2014 - 10:00

You’ve decided to create a physical task board for your team. Great! Now the question, what materials are best? White boards, pin boards, sticky notes? I’ve used a range in my time as an agilist, here are my thoughts.

Taskboard Physical Taskboards


Most teams who have been doing agile for a while with physical boards end up with whiteboards. These can look pretty professional, and have the benefit of being able to draw on them as well.

Some tips to consider if you plan to use a whiteboard.

Prestick and sticky notes don’t stick well to whiteboards, and they end up leaving marks on the board. It’s better (if more expensive) to invest in a magnetic whiteboard and either lot of magnets, or in magnetic task cards. You can buy flexible magnetic vinyl sheets that are erasable like a whiteboard, and cut it up to make task sized cards. It does mean you need to erase the cards each sprint, if you’d prefer not to, just get a bunch of small magnets and then use non-sticky paper (like note cubes) for tasks.

Lots of people use vinyl tape to create lines on their magnetic whiteboards. This is great until you decide to change your columns. The tape ends up marking the boards. A simpler solution is just to draw the lines in a permanent marker, that way they won’t get erased. When you want to move the lines, simply trace over the permanent marker with a whiteboard pen, and magically it erases icon smile Physical Taskboards

Another thing to consider is getting the whiteboard on wheels, that way you can take your task board into meetings like sprint planning. Personally I find it a bit clunky, and I’d rather have more space by mounting the whiteboard on a wall.

Finally remember to have enough room around your whiteboard for a standup. Lots of people have then on walls between 2 desks, or passage ways and then people struggle to all stand at the board for the daily scrum.

Pin boards

A cheaper alternative to whiteboards is a pin board. Again post-it notes don’t stick well, so you need note cards and lots of pushpins. A tip, make sure the pins you get are easy to use with a plastic head, rather than flat metal drawing pins and that the board is not too hard. I have seen many team members curse with sore fingers from bad pin boards/pins. String is great to use to create lines on a pin board.

A problem I’ve seen with pin boards is that if tasks move around a lot, then the task cards can get a little ragged. A bit of tape over the top where they get pinned can solve this.

One benefit for pin boards is that if you use a tool as well as a physical board, you can print your story cards.

As with whiteboards decide if you want the pinboard to be portable or not. These are definitely a bit easier to make portable than whiteboards, especially if you get a fairly small pinboard. If that’s important to you, this might be a better option.

Walls and Windows

If ordering a whiteboard or pinboard takes 4 weeks of procurement and forms in triplicate, consider just using a wall or window. Masking tape is perfect to create lines, and you can stick stuff to the walls with prestik. Note the prestik will mark the walls and potentially pull off paint, so be sure that’s okay with the office police first icon smile Physical Taskboards Again post-it notes don’t stick to walls well, although they stick fantastically to glass, so if you have a window instead of a wall, post-it notes are great.

A simple alternative that we use a lot is just a piece of flipchart paper stuck to the wall with masking tape, then stick the post it notes on to the paper. It works great, and it has the benefits of being easily portable. This is  the option we use the most at Growing Agile, check out what our office walls look like.

walls Physical Taskboards


Categories: Companies

Peter Drucker on Knowledge Worker Productivity

Agile & Business - Joseph Little - Thu, 04/03/2014 - 05:31

In the Winter of 1999, Peter Drucker had published an article on Knowledge Worker Productivity: The biggest challenge.  Here is access to the article.

Here is the second sentence: “The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and knowledge workers.”

Here is a quote from some key ideas in the article:

Six major factors determine knowledge-worker productivity.
▪ Knowledge-worker productivity demands that we ask the question: “What is the task?”

▪ It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge Workers have to manage themselves. They have to have autonomy.
▪ Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers.
▪ Knowledge work requires continuous learning on the part of the knowledge worker, but equally continuous teaching on the part of the knowledge worker.
▪ Productivity of the knowledge worker is not—at least not primarily—a matter of the quantity of output. Quality is at least as important.
▪ Finally, knowledge-worker productivity requires that the knowledge worker is both seen and treated as an “asset” rather than a ”cost.” It requires that knowledge workers want to work for the organization in preference to all other opportunities.

Very interesting ideas.

Categories: Blogs

Setting Expectations

George Dinwiddie’s blog - Thu, 04/03/2014 - 03:50

Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.” and changing the post to reflect his original intent.

There’s more to this business of setting expectations.

First of all, when we uses sensing estimates to understand our capability, we’re setting our own expectations. We can be pretty ignorant of those capabilities if we’re not paying attention. And, as software developers, we’re usually paying attention to myriad other details rather than our own capability. I know I do.

Years ago, I had a project lead who asked me to estimate how long it would take to fix a reported bug in some code written by a colleague who’d since moved to a different project. I looked at the bug report and made a list of the changes I would have to make. Then I estimated how long it would take to edit, compile, and verify each of those changes. I handed this annotated list to the project lead. He took one look at it and said, “You can’t do any task in 10 minutes. It will take you longer than that to checkout the code, find the place to change, and check it in again. Never estimate a programming task at under 30 minutes.” That’s when I realized that I was only estimating part of the required work, the programming part on which I was focused, not the necessary parts that enabled the programming.

I’m pretty terrible at tracking my own capacity as an individual. Not only do I tend toward a narrow focus that excludes that, but I forget to track interruptions. An interruption already gives me two things to think about at once, but tracking it would be a third. That’s a lot for one brain. I do better when I’m part of a team. The nature of team work allows me opportunities to pop up to a larger viewpoint more easily. And within a team that’s worthy of the name, it’s easy to be honest about both the capability and the uncertainty concerning it.

Even as we gain a better understanding of our own capacity, how do we set appropriate expectations for others? This is the crux of many estimation conundrums. Most developers are used to low trust relationships with those asking for estimates. They’ve been burned in the past with estimates being treated as guarantees, with estimates being treated as initial positions for negotiations, with estimates being accepted without the conditions assumed for the estimates. Who hasn’t estimated how long some task would take and then be given another task to do in the same time?

If we know how our estimates are going to be treated, we can apply “fudge factors” or “Kentucky windage” to compensate. If we know our manager is going to cut our estimate in half, we may double the number we offer. Knowing that our estimate is going to be treated as a commitment, we may pad it for contingencies. Knowing that we’re going to be subjected to interruptions, we may extend it based on interruptions in the past. How much we pad depends on whether our estimate is expected to be at the 100%, 99%, 90% 80%, or 50% confidence level.

In fact, the padding tends to go up radically the higher the expectation for the estimate. These two measurements are also related to the consequences for missing it. When someone expects an estimate at the 100% confidence level, they’re outside the realm of the natural world. There is always the possibility of something completely unpredictable, a “black swan” in Taleb’s terminology. With that unreasonable level of expectation, people often couple it with a sense that if something does go wrong, someone should be punished. There’s no allowance for things outside of someone’s control.

There is always some things we don’t know, and some of those are things we don’t know we don’t know. A friend once devised Hughes Law: “On any boat maintenance project, there will be at least three unforeseen complications, at least one of which will follow this law.” He recommended taking your estimated time for the work, tripling the number, and incrementing the unit of time measurement. That two day job becomes 6 weeks. When we have an extreme level of uncertainty, then giving any number can make us nervous.

What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?

The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?

Categories: Blogs

Define Your Agile Transformation

Rally Agile Blog - Wed, 04/02/2014 - 19:56

At last year’s Technology & Innovation -- the Future of Banking & Financial Services conference in Sydney, Australia, senior executives repeatedly used the following keywords (even, at times, trying to outdo each other with them):

  • customer-first
  • agility  
  • transformation

The first keyword is easy to understand and confirms something we know, but often overlook: we need to be more “customer-aware” and listen to customers’ needs and wants, rather than assuming that we already know what these are.

Here's a good example of what it means to be customer-first: at the TUANZ (telecommunications forum) conference in New Zealand several years ago, three telcos made presentations. The first two went up to the podium and showcased their new glitzy, glamorous products, only to face a barrage of questions from the audience about their seemingly less important products and features. The third presenter took the stage with a simple message: “This is what you’ve been asking us for -- and this is how we’ve delivered it.”  

You can guess which company received the most applause and enjoyed greater business opportunities. This simple message really resonated with me and has defined my approach to business ever since.


The second keyword, “agility,” is more ambiguous. What do senior decision-makers really mean by agility?

It doesn’t require poetic licence to interpret agility as adopting Agile concepts -- such as the ability to work efficiently with minimal waste; delivering in shorter, faster cycles; divesting the big, overarching programs to smaller, value-focused initiatives; focusing on a collaborative, transparent culture; and being able to change and adapt swiftly to meet changing market conditions or a customer needs.

(I hope I'm right in interpreting the executives' message.)


But what about the third keyword: “transformation”? At the Technology & Innovation conference, it was disappointing that no-one questioned what this term actually means. In my experience and from discussions with customers, there are two very different interpretations for the word transformation, used in this context:

  1. Optimising the IT department to deliver maximum value whilst focusing on quality and throughput (the major “continuous delivery” initiative recently announced by Australian telecommunications provider, Telstra, is a good example of this)
  2. “Organisational transformation,” where organisations look beyond IT to fundamentally changing the very way they’re structured

As an Agile practitioner and coach, I see Agile as a set of tools and concepts we can use to deliver fantastic solutions and enhance our customers’ experience. This does not mean Agile is solely focused on the IT or engineering department: in fact, I would love to see the words “IT department” pushed to file 13 and hear more talk about the business delivery teams. After all, isn’t that why we’re here?

In most cases, when an executive is talking about transformation he or she actually means they want to optimise the manner in which IT work is flowed through their delivery systems. Hence the focus on scaling Agile, continuous delivery, and creating “Scrum teams.” There’s nothing wrong with this approach and indeed it is a necessary step along the path.

The bigger definition of transformation, however, delivers significantly greater value and has a far more wide-reaching scope. It includes bringing agility to areas such as legal, finance, HR, operations, real estate, and the executive suite.

Where Are You?

To deliver the greatest value from our delivery systems we need to look at all the pieces of the puzzle. Here are some questions to ask yourself in figuring out where you fall on the transformation path:

  • Do your funding regulations and approaches align with an Agile way of working?
  • Do you hire managers, leaders, developers and other personnel with the personality traits to support an Agile delivery approach?
  • Are your operations teams involved up-front and continuously throughout the delivery cycle, or are they the forgotten teams at the bottom of the cliff, where you push off a solution to the public and expect them to support it?
  • When it comes to real estate, are your office spaces fitted out to support a transparent and collaborative culture?
  • Are your executives trained to personally champion and lead an Agile approach?
  • Do the people who interact with your organisation’s customers understand the streamlined delivery approach of Agile, and align their work requests, funding, support, and communications strategies with this approach? In other words, are they part of your delivery team?

Now that you've thought about these questions, where do you come out on the transformation continuum? I would hazard a guess that some of these questions were hard for you to answer: you wanted to say “Yes” but if you were totally honest, your answer would probably be a “No.” If that’s true for you, then consider this an opportunity to start a discussion around how to really transform your business and delivery activities with a well-structured and disciplined delivery approach.

We do so many things right; yet the drag of the past, fear of risk, and loss of control is a millstone around the neck of progress. You can transform into an organisation that delivers customer-first products and services, to great applause and business success; and the path to your transformation begins with agility.

Get in touch with Steve, or find out more about Rally’s Transformation Services.

Steve Lawrence
Categories: Companies

The Missing Agile Value

Agile Management Blog - VersionOne - Wed, 04/02/2014 - 18:24

This post was originally published on

Author Carol Dweck has completely changed the way I approach the world.

I’m a smart guy. I’m no genius but I’m pretty smart. Through most of my life, I’ve been able to get by just by being smart. For the most part it has turned out to be a pretty good strategy. I complete tasks in less time by thinking about them longer, I demonstrate industry knowledge (thus impressing my bosses) because I can hold a lot in my big fat brain. The problem is, I allowed the world around me to turn my smarts into my identity. It became my brand, and I felt a constant subconscious urge to protect that brand. As a result, I would avoid any attempt at a challenge to my intelligence. Unfamiliar things were anathema because not knowing about them made me look not smart. I avoided anything above my cognitive pay grade, and chose the activities that allowed me to shine.

Kinda limiting, don’t you think?

Enter Carol Dweck. She wrote Mindset, a book I find myself recommending in just about every conversation I have. In it, she describes me exactly. I had, as she describes in her book, a fixed mindset. Someone with a fixed mindset believes that intelligence and abilities are fixed; you’re either born with them or you’re not. A growth mindset, however, is one that believes that intelligence is not fixed and that, with enough effort and grit, anyone can be brilliant. The message isn’t new; it’s basically a very detailed version of, “Whether you think you can or you can’t, you’re right.” But what is new, as she explains in her book, is the science and evidence behind that way of thinking.

She compares John McEnroe (fixed mindset) to Michael Jordan (growth mindset). John McEnroe would blame everyone but himself when he lost a match, but Michael Jordan consistently put in the effort to become the best basketball player ever. McEnroe wouldn’t allow himself to be labeled as someone who has something to learn, he considered himself a born tennis great. Jordan, on the other hand, was always learning, always trying to make himself a better player.

Since reading the book, I’ve looked at the world in a completely different way. Instead of looking for opportunities to show off my intelligence, I’m looking for opportunities to grow my intelligence. Instead of gravitating toward subjects with which I’m already familiar, I’m entering into new and unfamiliar domains. I’m learning about sales. I joined an indoor soccer team. I’ve always considered myself rather bad at sales and just plain awful at soccer. I’m no longer embarrassed to say that I don’t know something. Instead, I’m eager to learn about it. I don’t allow failing to result in labeling myself as a failure. Instead, I learn from it.

I value learning. And there’s a lot to learn in the domain of software development. Because it’s hard.

I believe the creators of the Agile Manifesto value learning as well. They just went about expressing it in a different way. Take a look at the first sentence:

“We are uncovering better ways of developing software by doing it and helping others do it.”

Imagine, instead, if this first sentence was written like this:

“We have uncovered the best way to develop software through academic research.”

We are uncovering better ways of developing software. We’re still trying to figure this thing out. We’re still learning. Just like doctors who say they “practice” medicine because they haven’t perfected the science, I think that we’re practicing Agile because we haven’t perfected the process. And I don’t think we ever will. That’s why we always have to be learning.

By doing it and helping others do it. By digging in, failing, and learning – we’re putting our reputations on the line by experimenting with software development approaches in settings where money is at stake.

Learning is everywhere in the Agile mindset. We learn from our customers through rapid and frequent feedback. We learn from each other through regularly scheduled retrospectives. We respond to change because we learn about shifts in the market. We rework and refactor because we learn that there’s a better way to lay down code. To truly be Agile means to be in constant learning mode. To be Agile requires a growth mindset.

Have you noticed that the term “best practice” is hard to find in the Agile canon? That’s because there really are no best practices. We implement, we retrospect, we tweak. With all that tweaking, how could we ever settle on a best practice? If we’re too focused on implementing the best way, we’ll never find the better ways.

I offer an additional Agile value: Learning over Best Practices. While there is value in best practices, we value learning more. I’d like to know where you stand on this. Please drop a comment or hit me up on Twitter at @johnkrewson. Maybe I can learn something from your feedback.

Categories: Companies

Why Your Organization Struggles with Agile

Agile Management Blog - VersionOne - Wed, 04/02/2014 - 16:51

StruggleIt’s the basics that are killing your organization’s Agile effectiveness.

You used to practice them, but then got sloppy.

Or you never really learned to practice them that well before the need to scale was pressed upon you, and now things are growing up and out too quickly to go back and shore up the details.

How do I know this?

I’m just playing the odds that your organization probably falls into that very large group that is struggling to realize the potential of Agile.  And I’m considering what I observe all too frequently to be at the root of the struggle.

We all know what we have to do if we want to get in shape, right? Eat better, eat less, and exercise regularly.  Simple.  So why does the fitness industry rake in tens of billions of dollars annually, while the incidence of obesity and diseases related to lack of fitness keep increasing?

Want to build a financial nest egg? Save and invest more, and consume less, of course.  Again, very straightforward, but current research indicates that 76% of Americans are living paycheck to paycheck. Why?

For both of the above, the answer is, more often than not a) the delusion that “the normal rules don’t apply to my situation”, and/or b) a lack of discipline.

Ineffective Agile adoptions, including enterprise-scale transformations, can be traced to these same two causes. In fact, this applies to most things that we human beings don’t follow through on.

So why am I pointing out something so obvious and so universal?

Because I don’t want you to fail.

I don’t want you to run out and buy the Agile equivalent of a Treadmaster 9000 and a “Get Rich Tomorrow” home study course, only to find yourself sick and broke a year from now.

Is your organization holding onto collaboration-killing and throughput-throttling processes, based on the rationale that your business domain or product or technology mix is more complex than that of everybody else who is practicing Agile?

Is it shaving the sharp corners off the parts of Agile that are uncomfortable, either leaving gaps or replacing what was removed with something softer and more accommodating of the status quo?

True, successful Agile enterprises are continuously inspecting and tweaking how they do things.  That’s how they get better.  But they are tweaking the application of the fundamentals, not the fundamentals themselves.

Even “seasoned” Agile organizations plateau, and then seek out some advanced Agile concept or technique that is guaranteed to take them to the “next level”.  But there is none.

No professional sports team’s coach says, at a post-loss press conference, “Well, we were just one or two trick plays away from winning this.”   No, what they actually say is, “We didn’t execute on the fundamentals, and it cost us the game.”

The secret to Agile success is that there IS no secret.  Success comes through relentless improvement in the application of a few fundamental concepts and values.  Your situation isn’t the rare exception.

Yes, this can be challenging, especially when the impediments that need to be addressed are rooted high-up in the enterprise.  If it was easy, every organization would be wildly successful, and lots of Agile consultants I know would be running Tilt-a-Whirls at carnivals all over this great country of ours.

But that doesn’t mean it isn’t worth the effort.  If you want to succeed, you don’t really have a choice.

Categories: Companies

It’s MAD to Put All Work Through Discovery

Constant Change - Aaron Sanders - Wed, 04/02/2014 - 16:15

I was sitting with a team when their manager came in and asked, “Hey. Are you guys finished with this feature?” The Scrum Master responded, “We haven’t even had time to even begin the discovery on it yet.” The manager looked surprised and said, “Oh, OK. Would you let me know when I can see […]

The post It’s MAD to Put All Work Through Discovery appeared first on Aaron Sanders.

Categories: Blogs

Sometimes I Just Need to be Pedantic

Learn more about our Scrum and Agile training sessions on

Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals.  Here are some examples:

Agile Scrum

This is not a thing.  Agile is a philosophy of doing software development.  Scrum is a particular instance of Agile.  Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”.  It shows a pretty fundamental gap in the writer’s knowledge.

As with any software development lifecycle (SDLC) framework…

Scrum is definitely not an SDLC.  Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC.  It is designed to be incomplete instead of complete.  SDLC’s are meant to be complete solutions for delivering software.  Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.

Next, the article mis-quotes by incorrectly capitalizing Product Owner and Scrum Master.  And in some sort of ironic error, puts “Scrum master” in quotes.  Yikes!

The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided.  There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc.  Some of them are even my clients!  I would be happy to provide direct references if needed.


Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.

Yes, remote work is bad with Scrum.  But it’s also just plain bad.  Don’t do it if you can avoid it.  All that Scrum does with a remote team is show you just how bad it really is.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

World, I am not a project manager

Business Craftsmanship - Tobias Mayer - Wed, 04/02/2014 - 14:19

I’m invariably surprised how often I get contacted by project management organizations, who want to guest post on my blog, or engage me in some other way to help promote their tools and techniques. Even after twenty years of Scrum in our industry, where the project manager role is noticeably missing, there is somehow a perception that a scrum master and a project manager are the same role. Or that there is still a place for project managers in an agile process. There isn’t. Here, verbatim, is a recent exchange with a tool vendor. Names have been changed to protect the misguided:

Dear Tobias,

My name is John Smith and I represent a team of devs called PM Tool Makers. We build advanced project management software for people with skill and expertise—like your audience. [That’s you, dear reader]

I’m currently preparing a Slideshare presentation on Project Management with 25 - 50 quotes from top influencers in the industry. As you may know, online presentations are currently one of the biggest (and fastest) means to reach great deals of people and Slideshare is no exception here.

I’d really appreciate if you could provide us with one quote of yours that people interested in Project Management could benefit from.

The presentation will be branded and you can see it below the link and you also see it in attachment

Looking forward to hearing from you - we’d love to have you included.

I appreciate being noticed, of course, but I usually get the sense that these guys are crawling the agile blogs and hitting on agilists indiscriminately. Kind of like the lonely guy at a night club who thinks maybe he’ll just get lucky tonight. Anyway, I responded:

Hi John.

Thanks for writing. It’s no secret that I don’t have much respect for the discipline of project management—in fact I’ve often written in opposition to it. I believe projects need to be guided, not managed, and that guidance best comes from the teams building the software and the users who use it. I find the role of project manager to be somewhat unnecessary overhead—at best a plug for a hole that people are not effectively stepping up to fill for themselves, usually due to autonomy and empowerment issues with the organizational system in which they work.

Management (of all kinds) is a twentieth century invention. Prior to that we had mentors, master craftsman, visionaries to guide us. I’d like to see a revival of that model.  

So, I’m not really the best person to offer you a quote. But here’s something, anyway:

Don’t manage projects. Instead guide teams to manage their own work, and to collaborate with their users. Let go of control. Listen to the voices of the people doing the work. Embrace uncertainty. Ultimately, create an environment where your job becomes superfluous.

Probably not the kind of thing you are seeking :)

Best of luck with your presentation, and your product.


I rather liked the quote. John Smith did not.

Hi Tobias,

Thank you for your quote, but necessarily—yes, is not the kind of I am seeking.

Thanks for your message and good luck!

My job, as I see it, is not to perpetuate the myth that project management is a useful discipline, but rather to challenge that old assumption. At the same time I believe I have a responsibility to socialize a different way of working to those good folk who find themselves in a dying profession. Others have different ideas.

Categories: Blogs

3 Undisclosed Tips for Digital Creatives

TargetProcess - Edge of Chaos Blog - Wed, 04/02/2014 - 12:50

Today is a great day to share some killer tips on how to get the best out of one’s creative potential. These tips would be of special help to digital creative individuals, that is, to anyone, who thinks for a living as they look at a screen. So, whether you are a graphic artist struggling for that elusive touch that would make a corporate identity unique, or a UX designer who wants to put together an intuitive interface, or a product owner looking to figure out what goes next in a product, or a project manager looking to facilitate a team’s performance, or a software developer crafting a piece of code, look no further.  This article is your philosopher’s stone for achieving top results.

philosopher's stone

So, friends, lend me your ears. To turn on this magical power of brilliant insights, one just needs to do these three simple things day in day out.

1. Wherever possible, spend the bulk of your most productive time, preferably in the morning, when your brain is fresh, doing a research online as to how others have done this thing that you’re working on at the moment. If you’re a graphic artist, make sure you not only dig out all possible images or ideas that can be replicated, but remember to throw all those links with images at the other fellow designers in your team. Not only will this help strangle their creative edge ensure that all the industry-accepted standards are followed, but they won’t need to spend any more effort on inventing original concepts. Leave no stone unturned. You need to chase each and every clue. For strategic decisions, make the list of step-by-step routines copied from how others addressed the same challenge. You will never do anything valuable if you fail to follow the proven routines that other people have followed many times before.

2. The second magic success ingredient is to expose the drafts of your work, or to have your incentives for strategic decisions bullied discussed by as many people as one can possibly get. Facebook is an ideal space for that. Remember to be consistent in sharing the in-progress sketches or ideas with strangers, who don’t know you personally and who are completely unaware of the particular context you’re working in.  They’d shoot their comments, wasting your time making their invaluable contribution to shaping up this great idea, or a graphic, or a piece of code you’re currently working on. Consistency is the key here. The more exhausted you get filtering out the rare grains of sensibility from the avalanche of clueless comments, the closer you’re to what you’re looking for. The logic here would be the same as on the picture below. One is more likely to build a snowman with plenty of snow, picking out those special unretarded pieces with care.

unassembled snowman

3. Finally, there goes the trickiest part. Once you’ve let out your finished and polished brainchild to the outer world, work to secure the right attitude to external criticism within yourself. You absolutely need to master the skill of  proving your worth based on each and every comment received from your network of personal and professional contacts. The smartest way to accomplish this would be to build a model that would transform the bites of criticism to a numeric value. You’d need to set a certain plank for yourself with this model. Once this value gets below this plank, you need to work harder on the points 1) and 2).

Repeat this cycle forever, and you will sleep serenely, like a baby, enjoying the bliss of reaping harvest from all your hard work.

Image credits:

Related articles:

2 Approaches to Focus In Knowledge Work

How Communication Factors In To Production

Non-Judgmental Communication for Agile Teams

Are You a Copycat?

Categories: Companies

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.