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?
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?
Things 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.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.
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?
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.
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
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.
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.
- #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
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?
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.
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)
When people see this swirling underwater world on the Axosoft’s GitKraken.com 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 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 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.An 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.Ink 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.Converting 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.The 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.Christina experimenting with purple ink
We sketched the different kinds of movement and considered frame rates and compositions.Justin (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.Production
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.Justin 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.A 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.Shane drops ink into the tank A 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.Justin 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.Post-Production
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.My 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.A 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.My 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.Distribution
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 GitKraken.com’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.
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
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.
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.
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.
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 indeed.com 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
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 Scrum.org 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.
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.
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 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+).
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 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. Step 3: Export to a .CSV File
The Export button is available next to the filters–easy!
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 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
- Create Axosoft work logs from Toggl time entries
- Create Toggl tasks from new Axosoft items
- Create new Axosoft items from Toggl tasks
- Create Toggl projects from Axosoft projects
- Create Axosoft projects from Toggl projects
- Create Toggle time entry from Axosoft work log
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.
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.
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.