Skip to content

Feed aggregator

Handling Work Left at the End of a Sprint

It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. This leads to a couple of questions I’ll address here:

  • What should be done with the product backlog item itself?
  • Should be it split or should it be carried it into the next sprint? Should the team receive any velocity “credit” for completing a portion of the story?
First, Be Sure the Item Is Still Important

When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.

I’m perhaps being overly pedantic here, but the point is that each sprint begins with the product owner making a conscious, deliberate decision about what the team should work on. If there’s unfinished work from the prior sprint, it’s very likely the product owner will want the team to finish that work in the new sprint. But, the product owner should still make an actual decision to do that.

(As a note, let me also say that I’m not suggesting you make extra work for yourself if you are using a tool that would make this difficult. All I’m saying is that work does not automatically move into the next sprint. The product owner must decide if the work is still valuable.)

Splitting or Carrying the Item Forward

When a product backlog is unfinished, teams are often torn on whether they should leave the product backlog item description alone (even though part of that functionality might be complete) or rewrite it to describe just the missing piece.

For example, consider a team building typical print preview functionality in a desktop application. If the team builds everything but the ability to page backward through the pages, it can either carry forward the original user story or write a smaller, replacement story like, “As a user, I can page backward while on the print preview screen.”

I recommend that if you are going to finish the story in the coming sprint, just leave it alone. Don’t rewrite it. Everyone is used to it as it’s written. Assuming it’s still of value to the product owner, it moves forward exactly as written.

However, if the remaining work will be deferred to a later sprint, write a new story that describes just that subset of functionality. IMAGE QUOTE: If you’ll finish in the next sprint, don’t rewrite the story.

Does the Team Earn Velocity Credit

I always want to take a conservative stance towards calculating velocity. This means that a team should only take credit for work that is truly complete.

So, in the case the unfinished product backlog item is rolling forward to be completed in the next agile sprint, do not take any velocity credit. The team instead earns all credit in the sprint in which the work is finished. Since I advocate working with average velocities anyway, this averages out and avoids the risk of overstating velocity.

But when the team splits the story and puts the remaining subset onto the product backlog to be done in the future, go ahead and take some amount of velocity credit. The team will need to do its best to estimate a fair number of points for the subset of work that was completed. And, even though it did not finish the entire original story, the team may give itself all the original points if it feels the story was larger than originally planned. I’d be reluctant to do that very often. But, it is OK.

Always Look for a Root Cause

Finally, whenever work is unfinished at the end of an agile sprint, the team should take time in the retrospective to consider whether it was caused by something preventable. Sometimes, it’s just bad luck or bad timing, such as a team member becoming ill or a problem being found late in the sprint that could not have been found earlier. But, it’s always worth considering whether there is a root cause and whether something can be done to prevent it from affecting future sprints.

What Do You Do?

How do you handle work left at the end of the sprint? And have you found good ways of minimizing how often you have work left unfinished at the end?

Categories: Blogs

Frameworks for large agile projects?

frameworksThings are getting more and more interesting with the use of agile in larger and larger projects. We now have a number of frameworks that we can use, such as LeSS, Scaled Agile Framework® (SAFe®), DAD and Scrum at Scale. These frameworks can all be investigated with a few clicks of your mouse. And in true style the internet has a number of people telling us that these frameworks are bad. That they are prescriptive, or that they lack flexibility. If you look you can find the flame wars where you can get messages such as:

  • Frameworks are bad and that you should simply make your own approach up
  • My framework is better than your framework
  • Frameworks are not agile
  • And indeed many others

I have a different view. These frameworks contain many years of experience from people who have been working in the software industry and have a rich experience. They have recorded their ideas and given us information about things that work. They are uncovering better ways of developing software by doing it and helping others. Where have I heard that before? Of course if you think that you have more experience than all these people combined, then of course you should go it your own way. But if that is true, please tell us what your experiences are!

So which framework matches your needs best? Now that really is something that you can only answer, although you can take advice. All of the frameworks have something to recommend them, and while they are all built on what turns out to be very similar foundations, they do sometimes assume a different starting point. Some are for people who are more experienced, while some offer more structure to help you get started.

All of the frameworks include the principle of continuous improvement, meaning that they should all be seen as a starting point. As you learn, you will apply your lessons through inspect and adapt, or the familiar Deming cycle of PDCA. You own the framework that you adopt!

The warning is that frameworks are not a software development silver bullet. They will need investment and effort to establish and grow. How to design your framework, how to build it, and how to get the people ready are really key questions. Are you at a starting point for a framework or do you need to spend more time establishing your basic agile teams, educating the people or exploring your lean process?

The experience is that framework implementations which are nurtured and supported exceed beyond the expectations. While those that are established in the hopes of a quick and easy miracle, deliver as expected.

Good luck!

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Categories: Companies

How a team of 2 kids + adult rookies won a Robot Sumo competition

Henrik Kniberg's blog - 19 hours 36 min ago

Last night our Lego Mindstorms robot “Robit” somehow managed to win the Robot Sumo competition at the GOTO conference in Copenhagen!


Pretty frickin’ amazing considering that this was a big software development conference with lots of super-experienced developers competing, and our robot was mostly built by two kids – David and Jenny Kniberg (11yrs and 10yrs old) – the only kids at the conference.  Their robot didn’t just win once – it outmaneuvered and outwrestled the competing robots in every match!

Here’s the final, Robit to the left:

So how could a newbie team win the competition so decisively?

Was it our robot-building skills? Definitely not. We build mindstorm stuff maybe 1-2 hours per YEAR. We are newbies.
Was it our coding skills? Probably not. We do have experience coding. But very little in Mindstorms. And this was a professional software development conference, so we definitely didn’t have the upper hand on coding skills.
Was it luck? Nope, blind luck wouldn’t help us win every match in such a decisive way.
Was it because we (the adults) work at Lego? Nope. Didn’t use any special parts, didn’t consult with any experts.

So what was it then?

My guess:
A clear goal, a bit of research, and lots of integration testing!

First we set a goal. I wasn’t too optimistic – we’ve never done anything like this before, and I expected tough competition. So my suggestion was “Let’s built a robot that at least can stay in the ring and put up a fight!” So if/when we lose, it should not be because our robot ran itself out of the ring. Kids didn’t accept that – they said “No way. We’re gonna WIN!”.

Nevertheless, I convinced them to start in small steps. “How about you START by building a Minimum Viable Robot – one that can just move around the ring without falling out. Then keep testing and improving from there”. Agile, anyone? :)

We knew nothing about these kind of competitions so we started by looking at some youtube clips to see what kind of designs and strategies people were using. That gave us some ideas.

Dave invented his own robot from scratch and figured out how to program it to stay inside the ring. We weren’t sure how good it was at fighting though, so Jenny built us a second robot to use as sparring partner, the mindstorms base robot from the building instructions.


Upon integration testing in a makeshift ring, it became apparent that our first robot can’t win. It could navigate the ring beautifully, but it was simply too weak physically to budge the other robot.

So now we had a SmartBot (smart but weak) and a ToughBot (strong but stupid). We figured it’s easier to make the ToughBot smarter than to make the SmartBot tougher (because of the base construction). Plus we really are newbies at building these things, so we figured we’re best off using the default mindstorms bot as a base.

After installing some sensors and porting some of the code from SmartBot, our ToughBot was becoming a ToughSmartBot! We had our candidate! Robit was born! Time to train him up. The original SmartBot was gradually stripped of sensors and stuff and became DummyBot – our training dummy.

Bootcamp time!

We gave ourselves a very concrete challenge – Robit must learn to beat DummyBot! Not just once, but repeatedly. Because if Robit can’t beat a weak stripped down half-broken robot that stands still or roams around randomly, how could it have a chance in the competition? So we went through a bunch of cycles of integration testing and tweaking the hardware and software. We kept failing over and over (often in funny ways), but every iteration we got a bit closer to winning. It was 100% learning by experimenting.

One interesting thing happened along the way. We noticed on the youtube clips that many robots tried to lift and topple their enemies. So Dave built a pretty elaborate construction for that, and I helped write the code to control the lifter. Upon integration testing though, to our surprise, it turned out that the lifter wasn’t strong enough to lift the DummyBot under any circumstances. We would need another motor to strengthen it and we didn’t have the patience to figure out how. Bummer!

So with some regret we removed all hardware and code related to that. In theory it was awesome, in practice it was useless. We wanted to keep Robit simple and focused on one thing – putting up a proper fight!

I hate to admit it, but I really didn’t think we would stand a chance at winning the competition, so my ambition level was really just to have a robot that would put up a fight before losing. I didn’t want to ruin the kids hope though, so I kind of kept that to myself.

After dumping the lifter, Jenny built a simpler solution based on a pic we found online – a simple static bulldozer-like slope at the front of the bot. We figured that would help us get under the wheels and push or topple the opponent. Nothing unique, most robots have something like that in the front.


More integration testing. Started working pretty nice, Robit could now push the DummyBot around! However it was hard to get the right angle of attack. So the software needed some work.

After lots of iterating, Robit ended up with the following winning formula:

  • Start by driving forward and right for 2 seconds. That takes me a bit away from the line of sight of the other robot, and protects me from blind stupid robots that just charge without looking. Also gives me a better attack angle towards the side and rear of the opponent.
  • Main loop (the proactive “win the game” loop)
    • Turn clockwise until I see the opponent
    • Attack as long as I see the opponent! The attack sequence is “move forward 3 seconds, then move back 1 second”.
  • Secondary loop (the reactive “get me out of trouble” loop)
    • Am I at the edge of the ring (color sensor sees white/blue ground)? If so interrupt the main loop and BACK UP!
    • Is someone pushing me from behind (button sensors on my butt)? If so interrupt the main loop and BACK UP!

That’s it. A simple algorithm that turned out to generate a pretty advanced behaviour! During the actual competition, Robit managed to outmaneuver most opponents and keep hitting them from the side, and thereby avoid their weaponry. The “backup 1 second” part of the attack sequence was important because robots often get stuck in a deadlock while wrestling. By backing up and getting reoriented, Robit could turn and attack again and again, with new momentum each time. Once it even flipped a much heavier opponent on it’s head!

Here’s another example of a match – took about 10 seconds to outmaneuver and push out the opponent!

We were four people in the team – Dave and Jenny, me, and Lars. Although both Lars and I work at Lego (he is an employee and I am a part-time consultant), both of use are Mindstorm rookies. Due to time constraints Lars wasn’t able to participate in building or programming the robot, but during the competition he discovered that Robit had been damaged. If he hadn’t noticed and fixed that, we definitely wouldn’t have won.

As for my role, well, it was mostly coaching. I did end up writing most of the code, but that was in tight collaboration with the kids. Plus it wasn’t really that much code, once we figured out a good algorithm.

The big learning for me is how incredibly important and powerful it is to iterate fast! And to do end-to-end integration testing early and often. The usual agile stuff in other words.

We ended up with a robot that was mechanically one of the most simple ones in the tournament, and software that was also pretty simple but very well tested. So when Robit entered the arena he was already an experienced battle-scarred combatant! Robit kicked butt!

Here’s the source code – or “Robit’s Brain”


Initially I was hesitant to give it away, since we might compete again. But giving it away forces us to improve! So if we build another robot, it’s qualification test is if it can beat Robit in the test ring :)





Categories: Blogs

Hiring In 2015 Is Hard

More than a year ago we lost a good engineer to a new opportunity. I knew that engineer would be hard to replace, but I did not expect to still be trying to hire a replacement a year later. I haven’t seen this sort of tight market for developers since the height of the dotcom boom more than 15 years ago.

We’ve had trouble at multiple stages in the recruiting process. We’ve had trouble getting a good funnel, we simply don’t have many candidates. We have a robust interviewing process for Sacramento, but probably simpler than the process many Bay area startups use. And more and more we’ve had people decide to turn us down before and even after offers. One person simply emailed us to let us know just before an interview that “it wouldn’t be in either of our best interests” to conduct the final interview. Others have let us know that our business just doesn’t have enough of world changing mission.

I’ve also seen more candidates describing themselves as architects. Almost all of them have turned out to be more in the range of mid-level developers. There was a similar overstating of skills when the last dotcom started sucking up anyone who could spell HTML.

I don’t have any solutions to our year long hiring failure, but it’s time for us to try something different.

Categories: Blogs

Targetprocess v.3.7.9: Multiple Selection Custom Fields as Lanes

TargetProcess - Edge of Chaos Blog - Mon, 10/05/2015 - 20:17
Multiple selection custom fields as lanes

Starting with v.3.7.9 you can now use a multiple selection custom field as a lane on a view.

When you drag and drop the card between columns, you will add another selection to the list of values that have been selected for this card.

As an example, I have a Board view of Requests grouped by a multi-select custom field called ‘Area’. When I drag the card from ‘No Value’ to ‘Import’ and then to ‘Help Desk’, this request will have the ‘Import’ and ‘Help Desk’ values selected.

You can also filter by the values of this custom field. For example, if I filter the cards by ‘?Area.contains(‘Import’), then I see the cards in the columns that have at least ‘Import’ selected.

req by area

Fixed Bugs
  • #108913 Fixed Mylyn connector to work with v.3.7.8+
  • #86364 Fixed View scrolling problem on MacOS
  • #110114 Fixed “Invalid slice definition” error on a board loading when multi-select and drop-down CFs have the same name
  • #105778 Fixed broken view and view setup if custom field was renamed or deleted
  • #106283 Fixed confusing message on the ‘Relations’ tab if related entity belongs to deleted project
  • #109375 Fixed Epic/Feature lanes to show State, Project, Effort units
  • #109658 Fixed error when trying to add a tableau report widget to a dashboard
  • #109963 Fixed plugin exception: “The process cannot access the file”
  • #100581 Fixed: unable to change entity state if “Custom Field Constraint” mashup installed
Categories: Companies

Remote Retrospective Exercise

Scrum Expert - Mon, 10/05/2015 - 16:49
The retrospective is one of 12 principles outlined in the Agile Manifesto. If this is easy to do this for collocated Scrum teams, how can you achieve good results if you have remote members. In this blog post, Robert Matheson provides a valuable collaborative retrospective technique that can be used for distributed Scrum teams.This remote retrospective exercise is based on a digital retrospective board was ...
Categories: Communities

Agile Open California North, Berkeley, USA, October 9-10 2015

Scrum Expert - Mon, 10/05/2015 - 14:56
Agile Open California North is two-day conference that provides Agile and Scrum practitioners in California an opportunity for learning and networking. Practitioners and newcomers come together for two days to discuss, examine and otherwise brainstorm the most timely and relevant topics in Agile development today. Agile Open California North follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. ...
Categories: Communities

Who do you code for?

Diary of a ScrumMaster - Tom Howlett - Sat, 10/03/2015 - 00:23

Do you code for yourself?

Do you do it for the love of creating or the satisfaction of crafting something elegant? Do you do it for the discovery? Do you do it for the money, for the family you’re raising or the house you’re building?

Do you code for your team?

Do you share a common purpose and enjoy the camaraderie of building something together? Do you do it for what you might learn from each other?

Do you code for your manager?

Do you do it because you’re told to? For career progression? Do you do it out of fear?

Do you code for the customer?

Will your code bring your customers success? Will it win you more customers and grow your business? Do you have that entrepreneurial spirit?

Do you code for a user?

Does your code make someones life better. Does it remove the mundane and inspire change. Does it fascinate and immerse. Does it help people learn or create?

Who do you code for?

Categories: Blogs

Agile adoption: when it can go wrong and why you need to persist

TargetProcess - Edge of Chaos Blog - Fri, 10/02/2015 - 16:18

In case you did not attend Agile2015 Conference this year and your organization is in the process of adopting Agile you may find a recording of this panel discussion inspiring and insightful. Just several conclusions:

Problems at the Agile adoption stage arise generally in one of the two basic situations:
A) The organization is primarily focused on increasing sales & profits, then the problem is a misalignment of objectives of Agile teams and the non-Agile organization. The problem is more at the organizational level.
B) If the organization is totally focused on delivering value and delighting the customer, then the problems might be at the team level.

Pasted image at 2015_10_02 04_07 PM

While all companies are turning into software companies, Agile is about so much more than just software development. Agile is a solution for the whole organization to become more innovative and successful by sincerely focusing on delivering value and delighting the customer. Frequently it denotes that changes are needed in the way the organization is run. However, as soon as there is a sync at all the levels in understanding that the traditional top-down approach is less effective in the long-term than the outside-in (customer-driven) one, this will not only foster the Agile adoption in a particular organization it will also benefit the whole economy:
– the customers for whom the work is being done
– the people who do the work
– the organization itself
– the society

Watch the recording of the panel discussion for more conclusions from:

Melinda Ballou, IT Industry Analyst, IDC
Steve Denning, Author & Management Consultant
André Grard, Senior Analyst, VDC Research Group
Tom Grant, Senior Consultant, Cutter Consortium
Ron Jeffries, Extreme Programming (XP) Innovator, Author, Coach, and Trainer
Jim Newkirk, VP of Service Engineering, CenturyLink Cloud (Moderator)

Categories: Companies

Ink Drops in Water

About SCRUM - Hamid Shojaee Axosoft - Thu, 10/01/2015 - 20:33

When people see this swirling underwater world on the Axosoft’s page, they think we went deep sea diving to capture the footage. That was the intention: create an entire, abstract world–one where a kraken might hang out–to introduce our new git client (that doesn’t suck). “Ink Drops in Water” is the name of this video background and the two things people always ask after they watch it is, “How did you make those videos?”, and “How did you talk your company into letting you do that?”

Axosoft GitKraken WebsiteAxosoft GitKraken Website


When we pitched the idea to our CEO, Lawdan Shojaee, she said, “Go for it!” Originally, she had asked our creative team (Justin Roberts, Christina Lopez, and myself, Shane D Rymer) to come up with something “totally different” to help market the beta launch of our new product, Axosoft GitKraken (GK). Lawdan’s positive response was not a surprise because at Axosoft, we aren’t afraid to take risks, in fact, it’s one of our company values. For us, creating original artwork is not only a smart risk because it reflects sincerity to our customers, and therefore, trust, but it also demonstrates our support of the ‘A’ for ‘Arts’ in the STEAM fields, an educational initiative that we are passionate about.

If some companies are wary of artwork, it may be that creativity is difficult to grasp and its results are unclear. Perhaps then, a better understanding of the process and impact of creative work, would encourage companies to take more creative risks. I hope sharing how we created the “Ink Drops in Water” video, gives you some insight into the creative process and also inspires some ideas. You may even want to join our team!

Concept and Development

We began by learning about Git and working with GK (by we, I mean, Christina and I because Justin is actually the UX designer for GK). One thing that immediately stood out was the colorful graph.

GitKraken Graph DetailGitKraken Graph Detail


The graph is really at the heart of GK as it illustrates version history in a fresh and clear way. We knew we wanted to do something similarly visual and dynamic. Playing on the theme of the mythical squid-beast, we had the idea of ink in water. After experimenting with this medium, we discovered that ink intricately branches as it moves through water.

03 Initial TestsAn initial test with blue ink in water


We also observed that when different inks mix, patterns emerge. The blending of these fields of color is a perfect metaphor for version control. Our idea was to create a new way of understanding basic Git actions such as: push, pull, commit, and merge, with the evolution of hues through space and time.

04 Ink CollectedInk that collected on the side of the container during testing



A space, that’s all we needed, and maybe some ink. At Axosoft, we have spaces called ‘Flex Rooms’ which can be used for just about anything we need. We converted one into a temporary production studio.

05 Axosoft Flex RoomConverting a Flex room into a production studio


We set up a couple of tables, one for materials and the other for filming. We each brought in some glass containers from cylindrical vases to spherical bowls, but ultimately, our main container was a small fish tank placed beneath a portable product light studio. I was particularly excited for this project because Axosoft had just purchased a Panasonic Lumix GH4 Camera for me to use in my video projects (yes, I’m a video nerd, and yes, Axosoft hooks us up with the best equipment so we can do our best work). The GH4 can capture Cinema4k (4096 pixels in width by 2160 pixels in height) footage at 100 Mbps! I knew from our testing, that the depth of field would be very shallow and that we would need a way to accurately focus. Also, the three of us needed to see the footage in real-time, without having to crowd around a 2.5” LCD on the back of the camera. The solution was to run a video feed from the camera to an HD monitor. For our shot setups, we used the tick marks on a metallic ruler for focus and depth. In the image below, you can see in the monitor that we were zoomed to about a one inch vertical span.

06 Production StudioThe Flex room production space


Although we had some idea of how to film the ink, we experimented with some basic drops to get a general idea of how the ink moved.

07 Christina ExperimentsChristina experimenting with purple ink


We sketched the different kinds of movement and considered frame rates and compositions.

08 DiscussionJustin (left) and Shane (right) discuss how to shoot the ink


Once we had all the materials and equipment setup, we were ready to start video capturing.


There were so many factors that could be combined to create an infinite variety of footage, such as: the shape of the container, cold vs. hot water, still vs. moving water, the color and type of ink, the manner in which the ink is injected, lighting, composition, frame rate, angle, lens type, focus… so many possibilities, it was mind blowing! So, we just dove right in. I pressed the record button and Justin added one drop of blue ink to the water.

09 First DropJustin drops the first recorded ink


We filmed it from underneath so that we could see the bottom of the water’s surface and how it actually dropped into the water. Cool, but too fast for our frame rate.

10 First Drop FrameA frame from the actual footage of the first drop of ink


We spent the next 4 hours filming and produced about 120GBs of 4k footage. The following series of images shows us adding inks to the side of the tank and filming as the ink slowly dripped down the side. We loved the stripes, so we filmed this effect for fifteen minutes.

11 Shane drops inkShane drops ink into the tank 12 Frame from VideoA frame from the video captured in the previous image


We would watch the monitor to decide if we should continue in a particular direction or whether we just should cut and try something different.

13 Justin and ShaneJustin and Shane discuss what to do next


In between shots, we would have to wash the tank out completely, dry it, and make sure the tank was free of fingerprints. Then, we would refill the tank and carefully place it back under the studio lights. This process was literally rinse and repeat.


I spent about three times longer in post than in production, and honestly, a blog could be written just about how I edited the videos. But the short of it is that once the footage was captured, I transferred it to a drive and then imported to Adobe Premiere. I cut the best footage into a twelve minute video. We reviewed this long video, and then I re-cut it based on the best of the best of those shots which turned out to be about 1.5 minutes of video.

14 WorkspaceMy workspace in Adobe Premiere


Next, I incorporated motion graphics using Motion 5, that drew metaphoric connections between the basic Git commands and the ink. For example, when the ink was swirling, the colors would blend horizontally, which is very similar to what happens when one branch merges with another. I combined that footage with a typographic play of the word ‘Merge’ blending chromatic aberrations of itself.

15 MergeA frame from the final video


Since the graph actually forms upward, I vertically flipped the video footage so that the ink appears to be moving opposite gravity which adds an interesting and unexpected dynamic to the movement. Using elements from the GK user interface, I made a connection between a “Pull Request” and one dot of ink.

16 Motion SpaceMy workspace in Motion 5


I continued drawing metaphoric connections between Git concepts, GK user interface elements, and the ink footage until the video was complete.


The final stage in the process was to connect the video to the website. For this, I had to reduce the footage to about 30s in length. The Cinema4k footage at 4096 pixels by 2160 pixels was resized to to an .mp4 just under 1280 pixels by 720 pixels which reduced the load size by 85%.

That’s a Wrap!

Thanks for reading about how we created the videos for Axosoft’s’s background. Again, I hope it inspires some ideas and encourages you to take more design risks. And if you’d like to take some of those creative risks with us at Axosoft, we’re always looking for talented people to make a “dent in the universe” with, so check out our available positions. Also, let us know what you think of Axosoft GitKraken.

Categories: Companies

Agile Turkey Summit, Istanbul, Turkey, October 9 2015

Scrum Expert - Thu, 10/01/2015 - 15:09
The Agile Turkey Summit is a one-day conference dedicated to the Agile software development and Scrum project management approaches that takes place in Istanbul, Turkey. International and local Agile and Scrum experts provide the content. In the agenda of the Agile Turkey Summit you can find topics like “Seven Strategies For Code Revitalization”, “The Secret to Achieving Sustainable Agility at Scale”, “Agile leadership for agile times ...
Categories: Communities

The evil of tracking tools in the sprint

Agile Game Development - Thu, 10/01/2015 - 04:49
After 8 years of training and coaching teams I've noticed some very obvious patterns and anti-paterns.  One of them is the impact of bringing tracking tools into the sprint.

These tools are primarily used to:
  • Build the sprint backlog
  • Update the estimates during the sprint
  • Display sprint backlog details during the daily scrum
  • Spit out the sprint burn down
I understand that some teams, that cannot avoid being distributed, want to use such tools, but I rarely see them as positive for collocated teams.  It's not the fault of the tools, but how they are used.
One of the primary aims of Scrum is the boost in productivity seen with teams that have a sense of ownership in how they run their sprints.  Teams with ownership are accountable for their commitment.  They enjoy their work more and they explore ways to improve.
Sprint tracking tools can get in the way of that by:
  • Not allowing an "all hands" approach to managing the sprint backlog: one mouse, one keyboard, one operator.
  • The data in the tool is only brought out once a day because there are not enough licenses, developers don't want to learn the tool, or the extra effort isn't worth it.
  • The team's ability to customize the artifacts (task board, burn down, etc) are limited by what the tool can do.
  • The metrics of the sprint (sprint velocity, burn down), and even individual developer progress can be monitored by management.   Guess what happens when a developer or team is asked why their burn down is not diagonal enough?
  • Making the daily standup a status reporting meeting by focusing on individuals.
Even if the tool is being used in benevolent ways, the team can suspect otherwise.  In organizations that are trying to grow trust, this can be a killer.
Also, teams need their sprint backlog to be radiated at them.  Tools refrigerate the backlog by storing it in some cloud.
When I bring this up, I often hear from the Scrum Master that the tool makes it easier to do their job; tracking the sprint and producing the burn down or that there is no wall space.  It's often news to such Scrum Masters that their role is not to be efficient creating the artifacts, but helping the team build ownership and trust...or just tracking down solutions, like a portable task board.  I don't blame them necessarily.  Adopting a tracking tool for sprints are often an interpretation of how Scrum should work in an amber or orange organization.  Teams in these orgs who are new to Scrum might even want tools in the sprint so that the "Scrum fad" has minimal impact on them.

The sprint backlog is owned by the developers on a team to help them organize and manage their shared commitment and forecast for achieving the sprint goal.  It serves no purpose external to the team.  
Courage, commitment, focus, openness and respect aren't always easy to instill, but it can start with a bit of tape and some index cards.

Categories: Blogs

Busting 6 Common Myths About Agile

Rally Agile Blog - Tue, 09/29/2015 - 21:56

As agile has grown in popularity, so have the misconceptions about it. In a recent introduction to agile webinar we asked our audience which of these common myths they’d encountered — here’s what they said:

Do any of these look familiar to you? Let’s dive into these a bit and separate truth from fiction.

Agile = Scrum

Quick: what’s the first thing you think of when you hear the word agile? For many of us it’s a “standup” meeting. Or maybe it’s creating a “backlog” of user stories that get delivered in a two-week “sprint.” Fact is, these are all elements of Scrum, a popular project management methodology used by many agile teams. So Scrum is a framework for developing and managing work, while agile is an umbrella term for approaches like Scrum that share a common set of principles — but this isn’t about the semantics.

Scrum is just one of many methodologies that build on agile principles (others include Lean, Kanban, Test-driven Development, and Xtreme Programming). Simply “doing Scrum” doesn’t make you agile.

To “be agile” means focusing on customer value and quality, delivering value incrementally, limiting work in process (WiP), enabling cross-functional collaboration, and striving to continuously improve. When agile fails to take hold or improve results within organizations, as Rally VP of Product (and former coach) Ryan Polk has discussed, it’s often because it only lives in pockets at the team level or because it’s executed poorly. Sure, scaling agile more broadly means mastering the fundamentals of Scrum, but it also means adopting an agile mindset in how your teams, programs and departments work together and communicate with each other.

If you haven’t already read the Agile Manifesto and its 12 principles, and thought about what “being agile” (not just “doing agile”) would look like in your own organization, there’s no time like the present.

Agile Means “We Don’t Have a Plan”

Equating agile with a lack of planning is one of the more insidious agile myths. We know its likely origins: the misguided observation that agile at the developer level seems allergic to functional specs, and the belief that adapting to change means abandoning whatever plan you did have.

Well, maybe you’ve seen the iconic “planning onion” before?  

While it’s true that agile approaches trade the lengthy, upfront planning process for a more adaptive, iterative process, planning is a very important agile tenet. It’s just that instead of making one grand plan, once a year, and hoping that it’s still on target six months later, you’re dividing your planning (like the work) into smaller chunks and committing to reviewing your plans on a regular basis. Why is it better to plan, and then plan to re-plan?

  • Short-range planning helps you control WiP, which means you can deliver more value, faster.
  • Midrange planning helps you communicate, make visible, and prioritize the most important work, ensuring small iterations add up to high-value increments.
  • Long-range planning lets you take the feedback from your incremental delivery and use it to steer the business in the right direction.
Agile Doesn’t Need Project Managers

This might be one of the most fear-provoking misconceptions about agile — at least if you’re a project manager in a non-agile environment — and it reflects a fundamental misunderstanding about the roles on agile teams, which skills are most valued, and the fact that changing your collaboration dynamic can make people work more efficiently, happily, and productively.

The truth is that agile needs project managers — but it’s likely you won’t be called a project manager (you’ll probably have a title like Scrum Master or Product Owner), and it won’t be your job to tell people what to do or when to do it. That’s because agile approaches value self-managing teams — whose success relies on collaboration, localized decision making, regular communication, and tools for visualizing and sharing WiP.

For example: are you good at working with stakeholders, managing expectations, and balancing competing priorities? Do you have a strong sense for business value? Are you comfortable driving vision and strategic direction, while collaborating with a team to make day-to-day tactical decisions? Then you might be a good Product Owner. Do you understand people – their motivations, fears and desires — and group dynamics (what makes a team better than the sum of its members)? Do you enjoy problem solving for people so they can do their best work? Then you might be a good Scrum Master. (Learn more about how traditional project management maps to agile project management.)

Multiple analyst firms predict that agile approaches will dominate other methodologies in the coming years, and software-driven innovation means agile is gaining a foothold across nearly every industry. The Project Management Institute has found that the use of agile methodologies is up 27 percent from just two years ago, and a PricewaterhouseCoopers survey found that nearly two-thirds of these agile projects are managed by certified agile practitioners. And even though it’s a bit of a misnomer often used by companies transitioning to agile from waterfall practices, search for “agile project manager” on and you’ll see that this is an in-demand role.

Agile Doesn’t Believe in Documentation

It’s true that the Agile Manifesto values "working software over comprehensive documentation." However, this doesn’t mean documentation has no place in agile approaches. It’s just that instead of assuming a project and its associated processes require comprehensive documentation, you should undertake and design project artifacts because they provide value. Rather than drafting pages and pages of requirements and use cases and process rules, for example, think about the minimum viable information that needs to be captured, with whom it needs to be shared, how to document it in a collaborative way, and how that documentation might help you continuously improve.

Think about the roles on a delivery team — how people spend their time and how the tasks they perform correlate to a project’s success — and you’ll probably conclude that success maps directly to the time spent designing, building, testing, and shipping … not the time spent documenting all those processes.

Some roles will rely more heavily on documentation than others: for example, our UX designers do a lot of ethnographic research and customer interviews before they work with teams to design and build features, and their results need to be codified and shared. And when we do sprint or planning meeting retrospectives, we like to document what we liked, learned, lacked, and longed for, because capturing that information helps us improve over the next cycle. The point is that documentation isn’t the point in agile; it’s a byproduct of the actual work, and like the work, it should be designed to deliver value.

Agile Only Works for Developers / Software

Agile may have started out in the technology realm, but like any set of effective practices, it has evolved and taken hold across a much broader audience. From finance and healthcare to communications and manufacturing, non-software companies — now finding themselves driven by software — are using agile approaches to improve their delivery, customer experience, and innovation. Organizations buoyed by the success of agile in their IT or engineering groups also have invested in extending agile principles and approaches into the executive suite.

Agile principles are now being applied to marketing, legal and human resources departments, and McKinsey recommends that companies should borrow agile approaches from their IT departments to build agility into their company DNA. No matter your organization type or your current way of working, wouldn’t you like to be faster and more transparent? Wouldn’t it be great to know that you’re delivering what customers really want? Don’t you want to know that you’re doing the highest-priority work and that you can reprioritize when your competitive, economic, or strategic landscape changes? Agile companies do this.

Agile Will Fix All Our Problems

You know better than to fall for this one, don’t you? No one thing is going to fix ALL your problems. When leaders have problems that need fixing, however, they tend to search for a silver bullet. Pinning all your hopes on a “magical methodology,” however, is going doom you to disappointment. Just as doing standups or buying an agile tool doesn’t make you agile, integrating agile practices into your IT group isn’t, by itself, going to turn your enterprise company into a nimble startup.

If you think of your company as having a fitness goal, then adopting agile approaches is like a workout. Exercising your agile muscles takes discipline and commitment, and if you do it on a regular basis, it can make you much stronger. But to meet your larger fitness goal you also need to change other habits: let’s say, eat well and get enough sleep. Similarly, your agile muscles become even more powerful and effective with supportive infrastructure — like the right training, a commitment to change, and engaged leadership.

Bust Your Own Myths

If you’ve encountered any of these myths about agile, it might be time to brush up on what you think you know. We’ve put together some resources for you to do this easily on our Discover Agile Toolkit page. Learn how to make the business case for agile in your organization, hone your agile practices, get the scoop on role-based training, and take agile to the next level. Or check out the Discover Agile webinar recording to get an introduction to agile, Scrum, and the ROI you can expect at your organization.

Jenny Slade
Categories: Companies

Upcoming Agile Retrospective workshops

Ben Linders - Tue, 09/29/2015 - 17:34
The workshop Valuable Agile Retrospectives explains the “what” and “why” of retrospectives and the business value and benefits that they can bring. Public workshops are offered in London, Istanbul and Olomouc. Continue reading →
Categories: Blogs

Shifting from Scarcity to Abundance Thinking

Over the past few months, I've read a few books on marketing. But I've also taken a handful of video training courses on marketing and have been listening to some enjoyable podcasts on the subject. Back when I was in college, we really did look down on the people majoring in marketing. This was the 1980s. And it seemed like they often chose that major because it didn't require any math at all. And to an outsider, the main skills they appeared to need were a firm handshake and a good golf game.

A lot has changed since then and I've become fascinated with marketing because of all the data that's available to marketers today. It appeals to my analytical side. So while consuming all this content on marketing, I noticed something. Individuals whom I thought would be competitors in that space were often endorsing one another.

Scarcity and Abundance Mindsets

And I realized this no longer happens as often as it should within the community of Scrum trainers and coaches. Too many professional Scrum trainers and coaches have shifted into a scarcity mindset. Each trainer then acts as though any win by another trainer is a loss for his or her own business. Their thinking implies there are only so many clients in the world and clients are to be divvied up like slices of a pie.

But what if that client someone else trains is then wildly successful and tells 10 or 100 or 1,000 other people? The pie grows and it can very likely grow large enough that everyone wins. This is an abundance mindset rather than a scarcity mindset.

The Founding of the Scrum Alliance

When Ken Schwaber, Esther Derby and I co-founded the Scrum Alliance, part of the plan was a credibility transfer from ourselves and the organization to other trainers. We knew that for Scrum to succeed in the world, it needed a lot more training and coaching than the three of us could or wanted to provide. And, approaching it with an abundance mindset, we knew the need for Scrum training and coaching would grow well beyond what the three of us could provide.

And that brings me to today: Many of us who make our livings training and coaching Scrum (or agile in general) seem to have reverted to a scarcity mindset. I'm generalizing, of course. There are some wonderful examples of people within the Scrum community who live an abundance mindset daily. I wonder though if it gets tough for them to continue doing so when many around them are doing the opposite.

We Are Partners and Future Partners, Not Competitors

One of the marketing books I read made an interesting point. The author said he never refers to others in his space as "competitors." Instead, they are "partners" and "future partners." And this is indeed what I noticed while participating in video training and podcasts from these marketing experts. Even when some of them could have viewed themselves as competitors since they sold similar products and services, they knew that if I bought a product from one of them, it did not preclude me from buying a product from the others

So, if you are a Scrum Alliance Certified Scrum Trainer or Coach, or a Professional Scrum Trainer, please know that I consider you a partner or future partner. You aren't my competition, and I'm not yours. Our competition is crappy products and all the forces of nature that conspire to make teams build crappy software.

And, if you're reading my blog looking for a training course, I hope you'll consider mine. But, it's a big world and I may not be in your area at the time you want training. In that case, I sincerely hope you'll consider training, coaching or at least reading the blogs of my "partners and future partners."

Finally, CSTs, CSCs and PSTs (my partners and future partners!): I encourage you to leave links to training pages, bios, blogs, etc. below.

As always, I look forward to everyone's thoughts in the comments below.

Categories: Blogs

How can Axosoft help me with billing?

About SCRUM - Hamid Shojaee Axosoft - Tue, 09/29/2015 - 15:00

If you’re reading this, perhaps you are mildly interested marrying the project management prowess of Axosoft with the billing needs of your business. You might work for an agency, be a freelancer, or have a general need to bill an hourly rate for your work.

The clock ticks ever forward.The clock ticks ever forward.

Axosoft is fantastic at tracking who is doing what, projecting ship dates, and more. Although it is not a full service billing software, our Work Logs tab can act as your first source of data.

Step 1:  Put Your Work Logs to Work

Work Logs are the source building blocks of your billing data. When your team performs work, they should ideally be logging a Work Log for each stretch of work. These Work Logs not only update the item’s remaining estimate and actual duration fields,  they also contribute to your burndown chart.

Log it log it log itLog it log it log it

You can add Work Logs by selecting an item and hitting W on your keyboard. You can also add a Work Log from the details panel or by right clicking on an item.

Step 2: Open a Work Logs Tab

All Work Logs are collected in your Work Logs tab. You can access this from the + sign where other tabs are available (for versions 15.2+).

Add Worklog tab

You likely only need Work Logs from specific date, a certain release, or perhaps from a subset of users. Simply set the filters that apply to your data needs.

Filter hereFilter here

The available filters will differ from the item filters you might use in any other tab. This is where the Organize Panel can provide additional filtering. Select the project, release, user, or team you need to fine tune the Work Logs displayed.

Use the Organize Panel for that extra layer of filtering.Use the Organize Panel for that extra layer of filtering. Step 3: Export to a .CSV File

The Export button is available next to the filters–easy!

2015-09-24 16_56_29

What Can I Do with This?

This is your data and this represents Axosoft’s endpoint and introduction of another application. For many teams, opening this .CSV file in Excel allows them to massage the data enough to arrive at their objective. Otherwise, it serves as a great format to import into other billing software.

What if I Use Toggl or Harvest? Possible integrationsPossible integrations

If your team makes active use of Toggl or Harvest, then you can take advantage of our Zapier integrations to active track time worked. Here are just some of the zaps available:

Toggl Harvest

Zapier allows you to create zaps of your own in case you have more specific needs that go beyond what is listed above. You can even check if your current billing software has any active Zapier integrations you might use.

Categories: Companies

How would I run an Agile transformation: Hamburger style!

Coaching Agile Teams by Lyssa Adkins - Tue, 09/29/2015 - 14:00

Ardita Karaj
Ardita is an Agile Coach and interested in Agile development and execution of IT/Software releases and applies Agile thinking on everything around her.

I can’t say I am “an experienced Agile coach” but I have seen three of them in big scale. In all three, the initiative has been from the Top (CTO, CIO, Department VP) as “Agile is the solution of the issues we are facing”. Issues can be different but more or less are always around expenses, ROI, fast delivery and also as a peer pressure since all the successful CIO/CTOs out there are benefiting from Agile tools and practices. So far so good.

Usually, the way it gets executed, it is with project/product teams.They are the first to attack since they deliver what we produce. An outside or internal person that knows about Agile, is assigned to work with delivery teams. There is some work done with Managers as well, to help them understand the new language the people will start using now on.

What I notice is, that after a while, the Top and the Bottom layers are running Agile in their own way with their own expectations, but the layers in between, Managers/Directors/AVPs, are stuck. They are still Managing details, day-to-day operations, Severity 1 issues, approve Gatings, control communications top-bottom and bottom -top, run performance improvements, …..They become bottlenecks and get very busy at it.

I think that the Top layer, needs to understand Agile delivery before they ask for it. As a rule, in an Agile delivery, you hit first the most visible/riskiest feature and then improve/add functionality on it. In an Agile transformation, this feature is seen to be Delivery process and that’s why, the whole work of the transformation is done around improving the process, making the process agile.

When I make two steps back, improving the delivery process, is the whole “product” you are delivering in a transformation. Some analysis, story mapping and story breaking need to be done, to understand what is the most visible/riskiest feature of this delivery process you will produce.

And from what I see, it is the Management layer. At the end, even the end delivery process will need to be managed!

So, I would start my Transformation with the Management layer.  At the end, even in an hamburger “the meaty part” is in the middle!


I would :

1- train  managers with Agile principles and thinking 2- train managers on how to identify issues in an Agile environment 3- make sure managers understand Trust (they have to go through that themselves before) 4- train managers on how to manager people  5- train managers to have their personal Kanban to control their work 6- give managers chances to test all of the above without dropping the Agile hammer all over the place        And then…. Ask managers to run the Transformation with their teams, starting with organizing the teams according to work flow. Maybe this approach will not see the BIG impact right away, but is the incremental way to run a full Agile transformation. By starting with the Management layer, the highest risk “feature” is done first. During that process, we will learn, improve, progress and evolve as per the context of the organization. Then, the rest of the Transformation value comes, incremental and with purpose in mind. By now, managers should know how to manager people, how to create a trusting environment, how to allow test/try/experiments and how to empower people. Delivering in an Agile way is the side effect that will come naturally and managed properly.

This post originally appeared on When Growing Up blog on 5/8/2013.

Categories: Blogs

Feedback en Continue Verbetering

Ben Linders - Tue, 09/29/2015 - 10:11
Een sterk punt van een agile aanpak is dat dat er in korte cycli, z.g. iteraties of sprints (Scrum) gewerkt wordt, en er steeds feedback momenten zijn. Het cyclisch werken met feedback zorgt ervoor dat het proces bewaakt kan worden, en informatie uit de feedback helpt om continue de agile werkwijze te verbeteren. Dit artikel beschrijft welke feedback er in agile is en hoe je die feedback effectief kunt benutten. Continue reading →
Categories: Blogs

Deleting Unit Tests

I regularly delete some of my unit tests, sometimes within minutes of writing them. Even as a TDD fanatic I’ve come to realize tests are just a means to an end. If I decide to write a constructor test when first designing a bit of code and delete it a few minutes later, nothing’s wrong. These sorts of initial tests can become redundant quickly since to you have to construct the object for all the later tests.

As you adjust to TDD there’s a tendency to see the tests as important code. Deleting them is the last thing you’d think of doing. It turns out just like with production code less tests are better easier to maintain and easier to refactor. And as an added benefit you test suite runs faster. Tests are path to good code and you get an added benefit of a regression suite. And besides everyone’s favorite checkins are ones where you remove more lines of code then you add.

Categories: Blogs

Scrum & Kanban Open Source Tools for Bugzilla

Scrum Expert - Mon, 09/28/2015 - 17:24
Bugzilla is a popular open source bug tracker created originally by the Mozilla Foundation. It has an open architecture that allows extending its basic functionalities. This article lists the Bugzilla plugins, called add-on in Bugzilla, that allows integrating an Agile project management approach like Scrum or Kanban around the bug tracking features of Bugzilla. There are currently 5 open source plugins that allows to add Scrum ...
Categories: Communities

Scrum Knowledge Sharing

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