Skip to content

Feed aggregator

Impediment: Network down time

Agile Complexification Inverter - Thu, 07/10/2014 - 06:03
I'm working with a large networking (telecommunication) company on a mission critical new initiative to replace existing B2B account services functions that are siloed and separate with a new sexy UI where all the services are aggregated in one portal.  The development has been underway for over one year.  It is touted as an "agile" program.  Yet an interesting impediment has never been resolved.  That is the internal WiFi/Lan systems appear to be overloaded with the strain of development, over utilized with the number of people that are squeezed into the floor plan (I call the sardine can).  This system fails quite frequently, it is a well know impediment to sprints being completed, stories integrated into the build, builds tested, access to the QA server, etc.  Yet this impediment remains after months and continued growth of the program.

I wonder if the problem is that management feels that they can't do anything about infrastructure at one of the largest telecommunication companies in the universe.  Perhaps they believe that the cobbler's kids should have no shoes - that is is just the way of the world.

I frequently wonder if this program was a client of the company would they cancel their service for the networking products and seek an alternative supplier.  I wonder if that would be an option for this program.  I wonder if this is a case of having to eat your own dog food - imposed by some evil VP to make the teams understand just how bad the customers have it using our services and administering them using the system we have provided them - but then I realize - no that would take real organizational ability and if it could be used for evil - then surely it would be as easy to use that super power to organize for good.  And since I can feel little organization, I assume there is no super power in existence.

So perhaps one step in the direction of making this problem understood would be to calculate the cost of the frequent network down times and make this cost visible.  I've done this before with other such impediments - with varying levels of success.

I just saw this article:
How Much Does Network Downtime REALLY Cost Your Business? [Shocking]It contains a link to a calculator - makes it easy... try it - you might like it.
What would you do?  Please leave me a comment with suggestions.
Categories: Blogs

Random Issues in the Agile Transformation Bridge

BigVisible Solutions :: An Agile Company - Wed, 07/09/2014 - 22:25

The other day I was thinking about the problems I have been seeing with clients. My thoughts expanded from the current team and organization concerns to more general scope of experiences with other transformations. Below is the resulting list of ideas, in no particular order and without fanfare. Let’s talk about it if you’d like to go deeper on your favorite!

Random Issues in the Agile Transformation Bridge


  • Managing by email doesn’t work well. Leading a transformation by email doesn’t work at all.
  • Documents are important. Leading by example is vastly more important.
  • Before you can scale Agile (or anything else) you have to have Agile (or that anything) to scale.
  • If the business around the teams does not change, the teams will work they way they always have and just use the new labels for what they do. And have more frustration.
  • Policies, procedures and processes send messages. These messages define your culture. To ignore the messages is to ignore culture.
  • Culture eats strategy for lunch. And dinner. And steals your lunch money. Unless culture is aligned with your strategy. Then it gives you lunch. And Dinner. And more lunch money in beautiful greeting cards.
  • Ownership of improvements is better handled by those who need to improve. That means improvements mandated by others rarely create the desired result.
  • If a team doesn’t have what they need to get the work done, asking them to work harder will not help much.
  • For every decision maker or specialized skill that is not dedicated to a team add two days to every request. For example, if the stakeholder needs to approve a feature change it will take at least two days to get an answer. If a meeting is needed, add four days.
  • 99% or more of the time everyone is doing the best they can under the circumstances. Check your system and environment for the root causes of failure, not your people.

The post Random Issues in the Agile Transformation Bridge appeared first on BigVisible Solutions.

Categories: Companies

New ScrumMaster Tips

Agile Management Blog - VersionOne - Wed, 07/09/2014 - 18:47


I recently completed a blog on PMs transitioning to a ScrumMaster role.  I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media.  The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them.  When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum.  I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team.  I didn’t say management leader or controller or mother of dragons.

The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team.  I am not a fan of “working” ScrumMasters, meaning they are also coders or leads.  They need to resist the urge to roll up their sleeves and dive in.  A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster.  Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city.  All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city.  I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier.  I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working.  Do whatever you can to keep impediments down and efficiency high!

The servant leader side of the role is rewarding but being an Agile champion is crucial.  If you are new to the role start to soak up as much knowledge as you can.  At the end of the day you serve as the Agile coach for the team.  You should know the ceremonies and fun ways to facilitate them.  I highly recommend joining groups out there in internet land.  If you have a local Agile group join it, attend the meetings and share your experiences.  You will never stop learning.  Your knowledge and ways to handle situations builds trust with the team.

Another piece of advice I have is to provide a fun environment for your team.  Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed.  Try coming up with fun ways to do the standups and retrospectives.  If your team has the personality for it a prank doesn’t hurt from time to time.  Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke.  That was one of my favorite pranks I’ve ever been apart of.  Soft dart guns can also be very interesting on Friday afternoon.

I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it.  That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!

Categories: Companies

Recent Enhancements to LeanKit

Enhancements have been rolling in over the past few months. Here’s a rundown of some of the latest features, including: Mass card updates Auto-subscribe settings Quick card adds Mobile app improvements Update Multiple Cards at Once The new multi-select option (Ctrl/Cmd + click) allows you to update multiple cards on a board at once. Remove cards that are […]

The post Recent Enhancements to LeanKit appeared first on Blog | LeanKit.

Categories: Companies

XM Principle 9: Scaling Patterns

Scrum Breakfast - Wed, 07/09/2014 - 12:32
XM scales as Scrum scales, by adding teams. Coordination can occur through the Product Owners, Scrum Masters or Team Members, depending on the scope of the issues involved.

When multiple teams work on the same module, they each own a sub-module, which will require another finer pass of Contract-First Design to create interfaces for sub-modules before those teams can be created. For example, within the engine module there is the fuel system module, the engine electronics module, the exhaust system module. Each module has an interface that loosely couples it the other modules and clear tests of their value and technical excellence.
Creating TeamsApplied at WIKISPEED, the first design decision is the fundamental architecture of the product being created, in their case a car. What are the main modules, e.g. engine, body, drive train, cockpit, etc., and what are the interfaces between them? Once the modules have been identified and the contacts between them created (see XM Principle 4: Contract-First Design), sub-teams can be created on each side of an interface to develop that module.

If capacity allows and velocity and quality metrics indicate adding more teams per module will improve velocity and quality, then multiple teams can work in parallel per module.

Each team owns their own integration and tests, no team is “done” with an increment of their module until all tests pass, including tests that it complies with their module’s interface and no additional connections have been introduced.
Team CoordinationIn XM Scrum of Scrums, teams consist of 4 to 5 people, including a Product Owner and Scrum Master. Each product owner is responsible for pulling stories from the Portfolio Product Backlog (or simply "Backlog"), and getting clarity when their team needs it on the customer visible value and Net Present Value each story is intended to deliver.

This clarity comes from the Chief Product Owner (CPO) who sequences and refines the Portfolio Product Backlog continuously. The CPO is not a senior role in pay or experience, but is simply the person available enough to keep backlog ready for the teams, answer questions, and have the most clear understanding of the customer visible value the Portfolio Product Backlog is aiming to produce. Ideally, the CPO is the customer, and the one paying for the product or service the backlog is aiming to produce.

On each team, each Scrum Master is responsible for accelerating the velocity of the team, i.e. the amount of work sustainably delivered each sprint. Sustainible implies that the teams are happy and that all work completed satisfies the quality metric called the Definition of Done. Scrum Masters have an additional job here, too: they collaborate with the Scrum Masters of other teams to negotiate the shared resources like space, tools, and modules, across teams.

In this way, a team of 5 has clear expectations for themselves on how to resolve the most common types of impediments: lack of clarity is handled ASAP by the product owner, lack of backlog is handled ASAP by the product owner, lack of visibility into team delivery trend/quality/happiness is handled as a matter of course each week by the Scrum Master, and resource constraints and coordination are handled ASAP by the Scrum Master."

Next: XM Principle 10: Partner Patterns

The 10 Principles of Extreme Manufacturing
Categories: Blogs

Gute Entwickler sind schwer zu finden!

Scrum 4 You - Wed, 07/09/2014 - 07:52

In einem Training, an dem ich letztens teilnahm, kam unter den Entwickler wieder ein Mal die Diskussion auf, dass es doch gar keine guten Entwickler gäbe und es so schwer sei, neue Mitarbeiter zu finden. Die Teilnehmer, eine Handvoll jahrelang in der Softwareentwicklung erfahrener Menschen, waren alle der Meinung, sie kriegen keine guten Leute, die Entwickler von heute wären alle nicht brauchbar.

Nach regem Kopfnicken und Zustimmung fragte doch tatsächlich einer der Anwesenden, was denn wohl die Gründe dafür seien. Diese Frage warf natürlich wiederum eine andere auf, nämlich: „Wer ist denn ein guter Entwickler bzw. welche Kriterien erfüllt dieser?“ Da es ein Training zum Thema Selbstorganisation war, haben wir uns einfach einige der Anforderungen an die jungen Bewerber genauer angesehen.

  • Zunächst möge der Junior Entwickler genug Erfahrung mitbringen. Wie soll denn der Junior Entwickler Erfahrung sammeln, wenn alle nach Junior Entwicklern mit Erfahrung suchen? Nun gut, nach diesem Einwurf erbarmte sich einer der Teilnehmer und meinte : “Ja, man kann den sicher auch einarbeiten, ist ja noch kein Meister vom Himmel gefallen“. Puhh Glück gehabt, unser Bewerber hat unsere 1. Anforderung mit Ach und Krach geschafft.
  • Der Entwickler sollte mit mehreren Tools umgehen können (es wurden so viele aufgezählt, dass der Platz auf dieser Seite dafür nicht ausreichen würde). Okay, einer kann ja nicht alles wissen, da waren wir uns alle einig. Aber zumindest die gängigsten Tools sollte der Entwickler im Schlaf beherrschen. Damit war auch der Großteil einverstanden. Vor allem sollte sich der Bewerber nur bewerben, wenn er tatsächlich die im Inserat angegebenen Tools auch beherrscht. Auch bei diesem Einwand wurde rege mit den Köpfen genickt.
  • Der Entwickler möge sich seine benötigten Informationen selbst erarbeiten. In diesem Punkt gingen wieder die Meinungen auseinander. Die einen bestärkten mit Kopfnicken, während die anderen meinten, eine gute Einarbeitung seitens eines Seniors wäre unumgänglich. Bei diesem Punkt wurde sehr schnell das Thema Wissenstransfer angesprochen und auch die Tatsache, dass Senior Entwickler ungern ihr Wissen teilen. Aber auch bei diesem Punkt waren wir uns größtenteils einig. Ein neuer Junior Entwickler könnte genau diesem Problem entgegenwirken. Wir würden einen Senior Entwickler aus dem Team zu den Bewerbungsgesprächen dazuholen, damit er auch mitbestimmen könnte, wer eingestellt wird. Da auch er derjenige ist, der den neuen Mitarbeiter einarbeiten wird.
  • Die Arbeit mit agilen Methoden wie Scrum, Kanban oder ähnlichem sollte für den Junior Entwickler selbstverständlich sein. Hier waren wir uns natürlich alle einig. Ein kompetenter Mitarbeiter, der selbstverantwortlich und selbstorganisiert arbeiten kann. Der cross-funktional arbeitet und über ein agiles Mindset verfügt. Oh ja, unser Herz ging auf bei diesem Punkt, und wir nannten noch viele weitere Punkte. Doch dann sagte einer: „Aber genau das ist der Grund, warum wir keine guten Entwickler finden.“

Was sollte das heißen? Wir waren alle doch recht verwirrt nach diesem Einwand.

Seine Theorie:
In einem agilen Umfeld sind Soft Skills gefragt. Wir erwarten uns von den Entwicklern, dass sie kommunizieren, sich mitteilen, diskutieren und Entscheidungen treffen. Doch viele Entwickler werden Entwickler, weil sie sich nicht austauschen möchten und sonst kein Interesse an Kommunikation haben. Hinzu kommt, dass sie gerne Vorgaben haben, nämlich genaue Vorgaben. Diese Vorgaben nehmen sie, gehen in ihre Kammer und coden, bis sie alles abgearbeitet haben. Doch in einem agilen Umfeld planen wir iterativ, wir lernen dazu und verbessern uns immer wieder. Diese Entwickler tun sich sehr schwer mit dieser Art des Arbeitens.

Er glaubte tatsächlich, dass die fehlenden Soft Skills, die im agilen Umfeld erwartet werden, bei vielen Entwicklern nicht vorhanden wären, und dass dies der Grund dafür wäre, warum sich so schwer gute Entwickler finden ließen.

Und auf diese Ausführung hin gab es erneut reges Kopfnicken.

Related posts:

  1. Systemische Fehler in kleinen Firmen
  2. DeutscheScrum
  3. Ken Konfuzius Schwaber: Der Weg ist das Ziel

Categories: Blogs

Living The Dream. Or Is It A Nightmare?

Derick Bailey - new ThoughtStream - Wed, 07/09/2014 - 05:29

Have you ever heard of Etsy? Or Ebay? Maybe you’ve heard of Twitter or Gawker? How about Crashlytics or Airbrake, or Raygun? Of course you have. These are well known names on the internet and in techie circles. I mean, who hasn’t heard of Twitter and Ebay, even outside of the techie circles? Maybe people who don’t use the internet.

But do you know what they all have in common? They all use MarionetteJS (or have used at one point) – the Backbone application framework that I created during my consulting days, a few years ago - somewhere in their projects, products and services.

And you know what? The success of MarionetteJS terrifies me.

Scared of success

The Best Thing I Ever Did

Around a year ago, I turned over the keys to the MarionetteJS castle. I was working for Telerik at the time, loving my job but unable to put in any real time and attention in Marionette. So along comes this random (to me) guy named Sam Saccone. He’s been using Marionette for a while and he wants to help in any ways he can. It starts out with grooming the issues list. It quickly turns in to him fixing bugs. Next up, he’s putting together releases. And before I know it, I’m handing him the keys to the castle. And you know what?

The best thing I ever did for MarionetteJS (other than creating it) was turning it over to someone else.

I have no doubt in my mind that the continued growth and success of Marionette is due to the team that Sam assembled around it. It’s an amazing team and they are doing amazing things. I was actively holding back the project with my inability to get issues resolved, move it forward with significant new functionality, clean up the ugly parts of the API, etc. I may have been good for Marionette when I created it and curated it in to v1.0 land… but it’s obvious to me, now, that I was the one holding it back. 

Living The Dream

Most software developers that contribute to open source projects have the dream of one day working on or building the next big thing. It’s human nature to want that kind of recognition and power and awesomeness. I got lucky with Marionette. I was in the right place at the right time, had the right set of skills and the right circumstances in which I could execute on my ideas. It worked out well for me and for the Backbone community at large. 

For a period of time, I was living the open source dream. I was the man in charge of something epic. I had the vision, the philosophy, the idea… I somehow created an open source community that actively sought to help others, in spite of me. I led the charge and set things in motion. I got to live the dream.

And then I left.

Is It A Nightmare? Cause I’m Scared.

When I look at the success of Marionette… when I watch videos of the guys from Etsy talking about what they are building with Marionette… when I see tweets showing screenshots of Gawker using Marionette… I get a little sad. I think to myself “what could have been…” if I had stuck around and not left Marionette when I did. Then I realize that the success of Marionette now is due to my having turned it over and I swell with joy and jealousy at the same time, at what the Marionette team has done. 

And then I run away screaming. Terrified.

The thought of my code… my projects… my baby that I labored over for near 2 years… knowing the mistakes I made, the dumb things I did… seeing my code in the hands of such amazing companies scares me. 

Here’s the thing… I want all the success and fame and D-List Celebrity status that being the founder of a “big” (ok, maybe medium-ish sized) open source project brings with it. But I don’t want the responsibility. I want to be the guy with the name, and I’ve been that guy for a while now. I want to be known as the one that started it all… and I am… but inside, I’m still a scared little boy that has no idea what to do with this.

On Success

People ask me to help them with projects every week. Every. Week. Sometimes every day. I’m glad I don’t have time. I’m sad I don’t have time. I’m flattered by the shear number of people that are using Marionette, and the amazing opportunities that this project has brought to me.

And I’m terrified of everyone on the internet seeing that I really don’t have any idea what I’m doing – no more than you, or the next person. 

Impostor syndrome? probably. Isn’t that the latest fad, anyways? I need to jump on a bandwagon now and then. Self deprecating? Definitely. “You are your own worst critic”, right? Well I’m a hell of a critic.

The Fear…

Have you ever wanted to punch someone and didn’t because you were afraid of hurting them? Have you ever punched someone anyways and realized how powerless you are, as they laugh at your attempt to hurt them? I think success is similar to that.

Most of us are afraid of failing. But I would bet that more of us are afraid of succeeding, than would admit to it. I know it terrifies me, sometimes. 

Categories: Blogs

How Workspace Improves Productivity

TargetProcess - Edge of Chaos Blog - Tue, 07/08/2014 - 22:57

Success in software development business depends on an intricate fusion of optimized individual performances, be it for a C-level executive, or for a junior software developer, QA engineer or UX designer. Naturally, stakeholders want to drive business results to the optimum, using the leverages they can control, as they are looking for the ways to foster productivity of teams and individuals. In the end, it’s people who take decisions, come up with creative ideas and make working software. That’s why it’s so important to design a harmonious workspace that helps people feel good and deliver their best work. Enough has been said on how stressful environments strangle performance. A stressful environment, the way I see it, covers not only work, but lifestyle-related stresses, such as tedious commutes, being a parent to a newborn or overspending energy on a pursuit unrelated to work. Employers pretty much have no control over such things. A sensible employer will surely be aware of the impact they make on productivity, but these are life choices that people make, when it goes about babies and hobbies; it’s a matter of personal responsibility. Commutes can be controlled, partially, either by setting up an office in a favorable location with decent standards of living and reasonable population density, or by allowing remote work. What stakeholders can control completely is workspace. Rather than brooding over utopian surroundings, it makes sense to focus on the things that can be improved in your office.

That’s exactly what we do in our company, Targetprocess. We are in product development, and this implies that enhanced creativity and optimized individual performance are essential for the company’s success. In this business the price is too high if people are coming up with faulty solutions, on all levels. We simply cannot afford being downtrodden by a dull office environment.

A well-thought-out workspace can help a lot with these 4 things (or activities):

#1. Informal exchanges

Very often, if not always, discussions on work-related issues occur anywhere but at a scheduled meeting. Such conversations can bring along some good ideas, from our experience. That’s why Targetprocess office has been specifically designed to encourage these informal exchanges. The office is made up of 3 round towers, and we have a lounge dining area in one of the towers, the Green one, where we carry free buffet lunches. There’s also an espresso machine with a counter, and this lunch space has snacks and supplies. This environment encourages people to talk and share ideas. Here’s a map view of our Green tower (we also have the Blue tower, and the Orange tower, the space takes about 11,000 sq feet in total):

green tower

The other two towers have coffee counters in the center, with bar stools and a cooler/heater nearby. Everyone is welcome to stop by, sit down and discuss something.

Another thing that we have in place to facilitate informal exchanges is a no-cubicle setup. Some of us had previously worked at companies with huge open spaces, which would be another extreme. Of course, people can talk freely when they sit in one large room, but the noise and distractions are horrible. So, we’ve arranged something in the middle and remodeled the original space in the towers as “slices of a pie”. Check the snapshot of the Blue tower:

the blue tower

These pie-slice rooms hold comfortable workspace for our feature teams. Each feature team is cross-functional, and includes software developers as well as QA engineers. They usually develop one piece of our product’s functionality. This workspace arrangement is more favorable for our development process than a maze of 50 cubicles in one open-space, looks like. And, of course, it fosters informal exchanges in feature teams.

#2. Focused solo work

This kind of work can also be facilitated by office space. We have silent rooms, with a lounge chair or a couch, available to anyone who needs some time alone. One of these rooms is located in our office library. A UX designer, or a software developer, or a company stakeholder, or anybody else can walk in to the library (we have 300+ books and counting), pick a book from a shelf, flip through the pages, sit down in an armchair nearby and get some insight. Actually, a library is not only a part of an office space. It is a part of our continuous learning culture, which is mega-important to us as a software product company. Here’s a picture of some bookshelves in the library:


#3. Visual aids

We believe in the power of all things visual. Nothing facilitates creative thinking and problem-solving more than having a problem sketched, visualized, diagrammed and dissected. Also, nothing can give a work status report faster than a crisp visual dashboard. That’s why our office sometimes reminds a school with many classrooms. We have whiteboards in every pie-slice room, and we’ve also used IdeaPaint to turn some of the walls into the renewable sheets for jotting down ideas, software architecture maps and what not. That’s how we visualized our production roadmap on an IdeaPaint wall a few years ago:

roadmap for 2 dev teams Targetprocess

A large digital screen is another tool that helps a lot with visualizations. Just one example, that’s how we feed the status of our production builds to a screen:

a screen with production builds in Targetprocess office


This whole visualization philosophy is very strong with us, and since our product is a visual management tool, we have many screens with boards in the office.

#4. The sweet things and “feel good” stuff

These are the small things that do not directly contribute to productivity, but help brighten up the environment and make it happiness-oriented. Imagine, after a dull commute in a rainy day, or after a night of bad sleep you walk in to your office… and this charming cat greets you  :)

a cat with the deer horns

This cat is a very influential guy, by the way. We use it as a token to identify who is in charge of automated test runs. The cat obviously feels some affinity with deer (this picture was taken at Christmas time).

It somehow happens that our employees care about the space around them. Such small things do not appear in the office by an executive rule. People use their own creativity to make their workspace vibrant. Take a look at this custom artistic installation at a QA engineer’s desk:

inspiring wooden clips

I believe each and every office can come up with things like that. Such DIY craftworks create a cozy environment at work, helping people feel relaxed rather than stressed out. When everyone is focused and still relaxed, that’s when the real good work happens.

There’s yet another dimension to office environments. Workspace can be improved not only with furniture, or artefacts, but emotionally. Harmonious emotional spaces facilitate improved individual and group performance as much as harmonious room spaces, if not more. But this would be a subject for another article.

Related articles:

5 Things We Need for Sustainable Performance at Work

Cognitive Endurance Basics for Software Development

Continuous Problem-Solving Is No Accident

Top 5 Non-Office Brain Killers

The Perils of Facebook-ization

Do You Need an Open Office?

Our Library

Categories: Companies

Tuning your Scrum Standups

Rally Agile Blog - Tue, 07/08/2014 - 16:00

I recently taught my first Scrum workshop in a while, after a number of years of doing other work. The team was excited and ready to go. The next day, they held a daily standup in the traditional style. Each person answered the three questions:

“What did I do yesterday?”  

“What will I do today?”  

“What’s slowing me down?”

But since they were sitting together, it really felt forced. They had all worked together they day before, and so the readouts of “what I did yesterday” were pretty useless. At the same time, “what am I committing to do today” was something they needed to collaborate on -- not something they could each read out independently.

At the time, I reminded them that this wasn’t meant to be a status meeting -- it was a time for them to coordinate, and they discussed a little bit more amongst themselves. The three questions, meant to be a starting point, were a distraction from what they actually needed to talk about.

Not too long ago, I was at an event where Jim Benson talked about his mission to end the question, “What are you doing?” in the workplace. If work is being made visible through some kind of system or board, the answer should be obvious. You don’t need people to read out on this.

At Rally, most of our teams do daily standups, but I don’t see any of them following the traditional three-questions format. Most of these teams stand around a kanban board and then talk, right to left, about what needs to be done to move items forward. It doesn’t take long; the meeting is focused on the work, not the people, and the teams walk out the door with a clear plan every day.  

photo via Flickr, Creative Commons

This approach doesn’t ensure everybody talks. But over time, it’s obvious who’s involved … and who’s not.

Is it time for your team to stop going through the motions of the three questions in your daily standup, and start focusing on the work again?

Learn more about Standups, Scrum, and other Agile fundamentals with the Chalk Talk video series.

Alex Pukinskis
Categories: Companies

Pragmatic Manager Posted: Standup or Handoff

Johanna Rothman - Tue, 07/08/2014 - 15:27

I published a Pragmatic Manager yesterday to my subscribers. Normally, I let them enjoy the pleasure of being “in-the-know” about what I have to say this month for a while before I post the emails to my site.

Read the Pragmatic Manager here: Standup or Handoff.

However, I made a Big Mistake in where I will be speaking this week. I fat-fingered July 10 into July 19. What made it into the newsletter was July 19. Oops. I’m actually a panelist this Thursday, July 10, at Agile New England. The topic: Agile: Massive Success or Empty Buzzword?

My fellow panelists are Ken Schwaber and Linda Cook. We will have no shortage of opinions!

For example, I suspect that Ken and I might disagree on this very issue, of whether you can do agile with a geographically distributed team, and if you can have handoffs or you must do standups.

If you are near the Boston area, this Thursday, July 10, and want to see some sparks fly—or at least engage in lively debate—come to the Agile New England meeting July 10.

If you’re wondering how did this get past my reviewers, my copyeditor, and me? Well, we all make mistakes, don’t we?

Categories: Blogs

7 tips to improve your standup

Growing Agile - Tue, 07/08/2014 - 10:03
standup2 300x201 7 tips to improve your standup 1. Check your time.

Five minutes is too little, this means people are rattling off tasks but not really communicating. More than 15 minutes is too long, usually this indicates that some people are going into deep discussions which can be parked until after the standup.

2. Who is there?

Only people working on tasks with the team and the team should be there. Personally I think the Product Owner should be there as often as possible. IF you have more than 10 people in your standup its too big. Indicators are that most people don’t know what others are working on and so lose interest.

3. The 3 questions

The three questions: What did you do yesterday? What will you do today? Do you have any impediments? Each person should be answering these everyday. It helps if each person spends a few minutes before the standup thinking about what they will share and comes to the meeting prepared. It’s also important to listen to each person. When someone has been working on the same task for a few days, they should be offered assistance, and encouraged to break the task down.

4. Impediments

Most people answer that they have no impediments and yet the words they use indicate there are many. Take a look at our impediments video to learn how to listen for these words. We also have a great fourth question you can ask that will help uncover impediments.  Video & Workbook

5. Updating the board and burndown

The people doing the work need to control the board. It is their board. So if the ScrumMaster is doing this, get them to stop. Ask the team to update the board to reflect what they have just said during the standup. At the end of the standup, ask someone to update the burndown chart – which should be visible at all times, preferably next to the board and not in some online tool.

6. Checking the commitment expectations

Often teams have a great sprint except for the last 2 days when they realise they are not going to finish all their commitments. As soon as the burndown chart has been updated (by someone in the team)  ask the team if they are on track to meet their sprint commitment. If not, ask them what they can do to get back on track. Often a quick conversation with a Product Owner can result in simplification of a story in order to have it completed within the sprint. This is also an indication that the team could and should break down their stories smaller.

7. Start on time, same time everyday

Its much easier to attend a meeting if it is same time and same place everyday. Always start on time, even if there is only one person there. As the others arrive, don’t catch them up. Soon the team will learn to arrive on time and respect each others time and commitment to the meeting.


Categories: Companies

XM Principle 8: Continuously Deployed Development

Scrum Breakfast - Tue, 07/08/2014 - 08:00
Extreme Manufacturing requires going from an idea to a deliverable, working product or service in 7 days or less. How do you produce a new design in volume in such a compressed timeline?

Let's look at how traditional companies address the problem of new product creation: When a traditional car manufacturer designs a new transmission, they build a new factory.  Step one is to negotiate with various political districts for optimal conditions, e.g. access to roads & power, conditions for taxation, etc. Then they acquire the land, build the facility, hire and train the workforce, and configure the line. After many years of preparation, their customers can finally order a product for delivery.

How do you compress years of lead time down to a one week delivery cycle?

This Principle involves making the mass-manufacturing line flexible, so it can produce different products within a 7 day sprint. These products might be existing products, modified products or completely new products.

Achieving this operational flexibility might mean additive or subtractive rapid prototyping machines, or both. It might mean some machines or lean cells are placed on lockable casters so they can be wheeled in or out of the flow depending on the sprint goal. This often means that the team reconfigures the machinery following daily Scrum each morning. And this always means test fixtures connected to andon lights at all stages of the line.

R&D belongs at the head of the line. If the new product design team is within earshot of the volume manufacturing line, bi-directional communication occurs. If the R&D group deploys to the production line every sprint, both teams can work together to reconfigure the line to test and produce the new product. As cross functional skill grows, any separation between the R&D and manufacturing team dissolves and we simply have the cross-functional product team. Each individual has specializations, welding certifications for example, but through pairing they work on every aspect of the product flow from idea to customer delivery and support.

How are you going to get a truly marketable product, if you only have seven days to create a new product? See XM Principle 5: Iterate the Design. The objective is to create a first version within a week. Then iterate on the design to improve it as needed. Use the intermediate results to get feedback from customers, users and other stakeholders. Early designs will be big and clunky, making use of off-the-shelf components, but as you iterate the design and get feedback on it, you will zero in on your target.

For services, the story is exactly analogous. Ideally the service providers are the advanced marketers and innovators of new services, and within a sprint they interact with customers to improve the service and make the improvements available to the customers.

Next: XM Principle 9: Scaling Patterns

The 10 Principles of Extreme Manufacturing

This article was written by Joe Justice and Peter Stevens.
Categories: Blogs

What is an Estimate?

Software Development Today - Vasco Duarte - Tue, 07/08/2014 - 05:00
If you don’t know what an estimate is, you can’t avoid using them. So here’s my attempt to define what is an estimate.
The "estimates" that I'm concerned about are those that can easily (by omission, incompetence or malice) be turned into commitments. I believe Software Development is better seen as a discovery process (even simple software projects). In this context, commitments remove options and force the teams/companies to follow a plan instead of responding to change.

Here's my definition: "Estimates, in the context of #NoEstimates, are all estimates that can be (on purpose, or by accident) turned into a commitment regarding project work that is not being worked on at the moment when the estimate is made."
The principles behind this definition of an estimateIn this definition I have the following principles in mind:
  • Delay commitment, create options: When we commit to a particular solution up front we forego possible other solutions and, as a consequence we will make the plan harder to change. Each solution comes with explicit and implicit assumptions about what we will tackle in the future, therefore I prefer to commit only to what is needed in order to validate or deliver value to the customer now. This way, I keep my options open regarding the future.
  • Responding to change over following a plan: Following a plan is easy and comforting, especially when plans are detailed and very clear: good plans. That’s why we create plans in the first place! But being easy does not make it right. Sooner or later we are surprised by events we could not predict and are no longer compatible with the plan we created upfront. Estimation up front makes it harder for us to change the plan because as we define the plan in detail, we commit ourselves to following it, mentally and emotionally.
  • Collaboration over contract negotiation: Perhaps one of the most important Agile principles. Even when you spend time and invest time in creating a “perfect” contract there will be situations you cannot foresee. What do you do then? Hopefully by then you’ve established a relationship of trust with the other party. In that case, a simple conversation to review options and chose the best path will be enough. Estimation locks us down and tends to put people on the defensive when things don’t happen as planned. Leaving the estimation open and relying on incremental development with constant focus on validating the value delivered will help both parties come to an agreement when things don’t go as planned. Thereby focusing on collaboration instead of justifying why an estimated release date was missed.
  Here are some examples that fit the definition of Estimates that I outlined above:
  • An estimate of time/duration for work that is several days, weeks or months in the future.
  • An estimate of value that is not part of an experiment (the longer the time-frame the more of a problem it is).
  • A long term estimate of time and/or value that we can only validate after that long term is over.

How do you define Estimates in your work? Are you still doing estimates that fit the definition above? What is making it hard to stop doing such estimates? Share below in the comments what you think of this definition and how you would improve it.

This definition of an estimate was sent to the #NoEstimates mailing list a few weeks ago. If you want to receive exclusive content about #NoEstimates just sign up below. You will receive a regular email on the topic of #NoEstimates as Agile Software Development.

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to our mailing list* indicates required Email Address * First Name Last Name

Picture credit: Pascal @ Flickr

Categories: Blogs

Applying Little's Law in Agile Games

Xebia Blog - Mon, 07/07/2014 - 22:20

Have you ever used Little's Law to explain that lower WiP (work in progress) limits lead to shorter cycle times? Ever tried to illustrate Little's Law in an Agile game and found it doesn't hold? Then read this blog to discover that it is exactly true in Agile games and how it really works.

Some time ago I gave a kanban workshop. Part of the workshop was a game of folding paper airplanes to illustrate flow. To illustrate Little's Law we determined the throughput, cycle time and work in progress. To my surprise the law didn't hold. Not even close. In this blog I want to share the insight into why it does work!


It is well known that the average number of items in progress is proportional to the average cycle time of completed work items. The proportionality is the average input rate (or throughput rate) of work items. This relation is known as Little's Law. It was discovered by Little in the 1960s and has found many applications.

In kanban teams this relationship is often used to qualitatively argue that it is favourable for flow to have not too much work in parallel. To this end WiP (work in progress) limits are introduced. The smaller the WiP the smaller the average cycle time which means better flow.

A surprise to me was that it is exactly true and it remains true under very relaxed conditions.

Little's Law

In mathematical form the law is often stated as:


 \bar{N} = \lambda \bar{W} \bar{N} = \lambda \bar{W}

Here  \bar{N} \bar{N} is the average number of work items in progress at a certain time, and  \bar{W} \bar{W} is the average cycle time.  \lambda \lambda is the average input rate (new work items per unit of time). In stable systems this also equals the average throughput. In this case Little's Law is often (re)stated as


 \frac{\mathrm{Work\, in\, progress}}{\mathrm{Throughput}} = \mathrm{Cycle Time} \frac{\mathrm{Work\, in\, progress}}{\mathrm{Throughput}} = \mathrm{Cycle Time}


In practise one considers Little's Law over a finite period of time, e.g. 6 months, 5 sprints, 3 rounds in an Agile game. Also in practise, teams work on backlog items which are discrete items. After the work is done this results in a new product increment.

Under the following conditions (1) is exact:

  • The system is observed over a finite period of time,
  • The system is a queueing system.

A queuing system is a system that consists of discrete items which arrive at a certain rate, receive service after which they depart.

Examples of a queueing system. An agile team works on backlog items. A kanban team that works on production incidents. A scrum team.

Agile Game

An often used game for explaining the importance of flow to team is the game of folding paper airplanes. Many forms of this games exist. See e.g. [Heintz11].

For this blog's purpose consider a team that folds air planes. The backlog is a stack of white paper. 3 Rounds of folding are done. Airplanes that are folded and fly at least 2 meters are considered done.

new doc 5_1-1

At the end of each round we will collect the following metrics:

  • number of completed airplanes
  • number of airplanes in progress and not yet finished.

The result of the the 3 rounds are shown at the right. At the end of round 1 Team A completed 3 airplanes and having 8 unfinished airplanes. Likewise, Team B finished 4 airplanes in round 3 giving a total of 12 finished airplanes and having 6 unfinished airplanes in progress.

The cycle time are got by writing the round number of the sheet of paper when starting to fold the airplane. When done, write the round number of the paper. The cycle time for one airplanes is got by subtracting the two and adding 1.

Calculating Little's Law

The way I was always calculating the number for work in progress, throughput and cycle time has been

  1. averaging cycle time for all completed airplanes,
  2. averaging the throughput over all rounds,
  3. averaging the work in progress over all rounds.

When calculated at the end of round 3, for Team A this amounts to:

  • Average work in progress = (8+6+2)/3 = 16/3,
  • Average throughput = 10 (completed airplanes)/3 = 10/3,
  • Average cycle time = 22/10 = 11/5

Using (2) above we get: 16/3 / (10/3) = 8/5. This is not equal to the average cycle time of 11/5. Not even close. How come?

The Truth

The interpretation of work in progress, throughput and cycle time I got from working with cumulative flow diagrams. There are many resources explaining these, see e.g. [Vega2011].

The key to the correct interpretation is choosing the time interval for which to measure the quantities  \bar{W} \bar{W} ,  \lambda \lambda , and  \bar{W} \bar{W} . Second, using the input rate instead of the throughput. Third, at the end of the time period include the unfinished items. Last, in calculating  \bar{N} \bar{N} consider all items that went through the system.

When we reinterpret the results for teams A and B we get

Team A

  • Average work in progress
    In round 1 3 airplanes were completed and left 8 unfinished; a total of 11 for work in progress (11 airplanes picked up as work)
    In round 2 the team completed 2 airplanes and have 6 unfinished; a total of 8
    In round 3 the team finished an additional 5 airplanes and left 2 uncompleted; a total of 7
    When measured over 3 rounds an average of (11+8+7)/3 = 26/3
  • Average input rate
    Using the input rate:
    In round 1 the team picked up 11 new airplanes
    In round 2 the team picked up no additional airplanes
    In round 3 one new airplanes was picked up.
    An average input rate of (11+0+1)/3 = 4 airplanes per round
  • Average cycle time
    At the end of the third round 2 airplanes are left in progress; one taken up in the third round having a waiting time of 1 and one left from the first round having waiting time of 3 rounds. A total waiting time of 22 + 3 + 1 = 26 rounds.
    Averaging over 12 airplanes we have an average cycle time of 26/12 = 13/6 rounds per airplane.

Dividing the average work in progress by the average input rate we get 26/3 divided by 4 = 26/12(!). This is exactly equal to the calculated average cycle time!

Team B

In a similar manner the reinterpreted results for team B are:

  • Average work in progress = (13+14+10)/3 = 37/3 airplanes,
  • Average input rate = (13+2+3)/3 = 6 airplanes per round,
  • Average cycle time = (27 (completed) + 10 (unfinished))/18 (airplanes) = 37/18 rounds per airplane

Again, dividing the average work in progress by the average input rate we get 37/18 rounds per airplane, which again is exactly equal to the average cycle time or waiting time!

Note: the cycle time of 10 days is built up by (a) 1 airplane from round 1 (cycle time of 3), 2 airplanes picked up in round 2 (total of 4 rounds), 3 airplanes picked up in round 3 (total of 3 rounds).

What About Cumulative Flow Diagrams?

Now that we understand how to calculate the quantities in Little's Law, we go back to cumulative flow diagrams. How come Little's Law works in this case.

In the case of teams that have collected data on cycle time, work in progress and throughput Little's Law work when done as explained in the section 'Calculating Little's Law' because:

  1. the teams are kept stable by having WiP limits on the left most column ("To Do"); then the throughput is more or less equal to the input rate,
  2. the team has completed a fairly large amount of work items in which case the waiting time of unfinished work items can be neglected,
  3. when measured over the (large part of the) value creation process, the completed items per time period can often be neglected in the calculation of the average work in progress.

Little's Law (1) holds under the conditions that (a) the system considered is a queueing system and (b) the observation or measurements are done over a finite time interval. It then holds independently of the stationaryness of the probability distributions, queuing discipline, emptiness of the system at the start and end of the time interval.

Calculate the quantities  \bar{N} \bar{N} ,  \lambda \lambda , and  \bar{W} \bar{W} as follows:

  • Average work in progress  \bar{N} \bar{N}
    For each time interval considered count the total amount of work in the system and add any items completed in that time interval.
  • Average cycle time  \bar{W} \bar{W}
    Sum the cycle times for all completed items and include the waiting time for unfinished items and divide by the total number of items.
  • Average input rate  \lambda \lambda
    Add the total number of items that entered the system and divide by the total number of time intervals.

[Little61] Little, J. D. C. 1961. A proof for the queuing formula: L = ãW . Oper. Res. 9(3) 383–387.

[Heintz11] John Heintz, June 2011, Agile Airplane Game, GistLabs,

[Vega11] Vega Information System Services, Inc., September 2011, Basics of Reading Cumulative Flow Diagrams,


Categories: Companies

What does it really mean to be an Agile Tester?

Agile Management Blog - VersionOne - Mon, 07/07/2014 - 18:46

I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.

What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.

For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.

I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.

All for one

As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!

You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”

OK, allow me to elaborate…

For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.

It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.

It means that you embrace change; you collaborate well with your team members as well as those outside the team.

It means you know how to help other folks on the team automate tests and help drive exploratory testing.

It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.

It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.

It means you guide other folks on the team, helping them improve upon their testing knowledge.

It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.

It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.

It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.

It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.

It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.

It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.

It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.

It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.

It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.

In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.

It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.

It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.

And yes, it means you actually run tests too, whether they’re automated or manual.

Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.

If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?

Categories: Companies

Kanban Thinking: The Canvas

AvailAgility - Karl Scotland - Mon, 07/07/2014 - 15:51

Kanban CanvasLast week, at SparkConf, I announced a new website for Kanban Thinking, which is where I will add new material in a more structured way (I’ll continue to blog ideas here in an un-structured way!). The primary new piece is what I’m calling a Kanban Canvas – a sheet designed to be printed on A0 paper and used to collaboratively explore the model when designing a kanban system.

The canvas is built around the heuristics and related questions, with the goal being to co-create a design by exploring and answering the questions. You can see some more on this in the SparkConf slides below. Please visit the new site, download the canvas, and let me know your experiences.

And of course, let me know if you would like me to help facilitate your work!

Categories: Blogs

The Importance of Two Things in Agile

Agilecraft - Petri Heiramo - Mon, 07/07/2014 - 14:40

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example:

  • the product has been properly tested and there are no known bugs
  • the product has been integrated with its environment
  • code is clean and refactored
  • documentation is up to date

If we don’t have that state, it should be the most important thing the team works on achieving. It is generally much more important than adding any new capability into the product.

Because, if we don’t have that state, we don’t have 80% of what makes Agile really work. The team is really doing glorified waterfall. “Almost Agile”, but still not Agile. We also don’t know where the project really is, since there is an undefined amount of work remaining in the features created so far (which is exactly the key problem with waterfall based project management). Essentially, we fool ourselves.

For achieving this in software context, Extreme Programming is a necessary framework (or something very very much like it). Scrum and Kanban are silent on this, but it has always been an assumption that smart software teams are aware how critical it is and use it appropriately. For those who have not experienced XP for real, it is unfortunately too easy to dismiss the importance (because they just don’t understand how much it really changes the name of the game).

Relentless improvement

The second thing is retrospectives – the continuous process of evaluating the way of working (including achieving & improving the technical quality of the product).

Unfortunately, this is often the first thing teams omit in a hurry or when getting less excited about their work. This is a symptom of “work harder” belief gone wrong. Yes, there are moments when working hard (i.e. focusing on getting stuff done) is very important, but it should never replace “working smarter”. And dropping retrospection is exactly that.

All examples of really masterful people or teams exhibit retrospection. They spend time to understand the system and focus on finding behaviors that enable them to get more done at their normal effort. They look at the world with new eyes that allow them to rephrase their problem, thus opening opportunities to new innovative solutions.

Masterful teams understand the importance of potentially shippable outcomes, and continually retrospect any faults that escape their process. They want to understand how to further “error-proof” their work. Of course, it’s a work that will never completely finish or achieve perfection, given that things tend to change and some surprises always happen.

And it is not just the process they retrospect, they also look at other elements of their value delivery. How can we better understand our users real problems? Are we able to come up with innovative solutions? Are we creating a successful business? Do we have the right skills or enough variety in our team? Do we appreciate and support each other enough? Are we communicating effectively in our meetings and daily operation? Are we seeing the reality, or an illusion of some kind? Are our challenges big enough to maintain the drive we have?

And everything else follows

If we follow these two elements, we can distill all other practices and frameworks we need.

We probably need to plan what we seek to achieve in some way (e.g. Sprint Planning and release planning). And we also want to replan daily for surprises (e.g. Daily Scrum) and inspect that outcome with stakeholders (e.g. Sprint Review). And so on. We don’t have to choose Scrum as our framework – we can also choose some other metaphor, like Kanban – but the process does emerge from these needs.

We can also refine our general approach. Is an iterative and incremental approach right for all the things we do? Do we need to assign singular responsibility for certain parts (like prioritizing things to do)?

As a consequence, a masterful Agile team will have a great process, but that process may be unlike anyone elses’ process. And that’s the point – they have not copied their process, but evolved it through countless small improvements and experiments. That’s the heart of Agile.


Categories: Blogs

The Next 7 Habits of Highly Effective Coaches: Habit 13 – Motivate with Flow

Portia Tung - Selfish Programming - Mon, 07/07/2014 - 11:00
Habit 13 – Motivate with Flow

One of the greatest sources of satisfaction is achieving flow in what you do. Instead of motivating people through reward and/or recognition, create an environment where people have the chance to practice and get good at what they do. The satisfaction derived from flow will be greater than anything extrinsic has to offer.

Exercise: Free Flow

Identify a goal and a timebox (eg 15 minutes). Then do an activity in that timebox that enables you to get closer to your goal. Notice how you felt as you focused on the task at hand. What did you achieve? How can you flow again? How can you flow on demand?

For more information, see: Ted talk by Mihaly Csikszentmihalyi on Flow, the secret to happiness.

About This Blog Entry

The Next 7 Habits of Highly Effective Coaches is part of a mini series inspired by the style of Paul Coelho‘s “Manual of the Warrior of Light“. You can find the first 7 habits here.

Categories: Blogs

5 principles on quality and testing in the Agile context

Don't get better at scraping burnt toast; get better at not burning the toast in the first place."When you make toast, do you want to burn the toast and scrape it, burn the toast and scrape it  - or do you want to make the toast right before it gets to your inspectors?"  Dr. William Edwards Deming

Inspect-and-fix after the product is built is "scraping burnt toast".  This is inherently ineffective and unscalable. Learning how to not "burn the toast" is about improving how the development process works.
Tests are a way to clearly communicate expectation; establish expectations before, not after development.

Normal language is prone to misunderstanding and false agreement.  Tests, as a more structured medium, more clearly communicate expectations and ensure we get real agreement (or disagreement).

It takes less effort to communicate expectations before starting and meet them than it is to proceed with the wrong expectations and have to correct after having already built the wrong thing.Automated regression testing will lead not to tens, nor even hundreds of tests, but rather thousands of tests.  Therefore automated regression tests need to be deliberately structured for maintenance and performance.

Even minor problems with an automated testing approach or toolset will become untenable as the number of tests escalate.  Typical numbers of tests in an automated regression test suite can run into the thousands, not tens or even hundreds.
The issues that you face with scaling automated regression test suites are pretty much the same as that for scaling a development code base: duplication, clunky and/or complicated setup, inconsistent conventions, etc.  In essence, good automated regression test suite practice is about good development practice.Tests are a product asset.  They are a maintenance deliverable to make subsequent changes easier.

Because tests clearly communicate how a product behaves, they help with both the design and verification of subsequent changes.  An executable test suite (including data and environment dependencies) should be an expected part of a delivered product, not something that is used and thrown away after a project ends.Automated testing is not enough.  You also want ongoing exploratory, sapient testing.

Machines are good at inspecting for known expected behaviour.  Humans are good at exploring unexpected behaviour.  Human testing should focus on improving our understanding the boundaries and attributes of the solution space to help inform the design and development of future solutions.
Categories: Blogs

What question is your MVP asking?

N. Taylor Thompson wrote a blog post on building Minimum Viable Products that I was told was interesting but difficult to get through, so here's my attempt at an easier expression of the ideas:

A business model is a set of assumptions.Minimal Viable Products (MVPs) are the experiments used to either validate or invalidate the assumptions in a business model.
Every MVP should be asking a question.  The answers affect the next step you take.What question is your MVP asking? What does the answer tell you?

If the answer doesn't affect your subsequent behaviour, why did you bother asking the question? That is, if the next step doesn't change depending on whether the MVP succeeds or fails, then the MVP was a waste of time.
Different types of MVPs provide different types of answers.Your MVP can be worse than the final productThat is, not as slick, handicapped in some way, but still contains the essence of the solution.

SUCCESS: Indicates that you have a strong problem-solution fit

FAILURE: Could be because the concept is flawed OR it could be because the product isn't good enough yet.

N. Taylor Thompson calls this a Validating MVP.
Your MVP can be better than the final product.This is the essence of the Concierge MVP approach. Create a better product at an unsustainably high cost by personalising for every customer.  In essence, deliver magic and see if enough people are interested.

SUCCESS: Indicates that you have a market for your product, though you need to work out how to be profitable.

FAILURE: Time to pivot or move on.

N. Taylor Thompson calls this an Invalidating MVP.
Start with a Concierge MVP, follow-up with validating the details of the business modelN. Taylor Thompson suggests that for any situation with significant market risk, the most effective approach is to start by asking whether there is a market if the solution was magic, that is, with an MVP better than the final product (aka "invalidating MVP"). This is a more efficient way of detecting whether you're solving the right problem.  Only if that is successful should you worry about validating the other assumptions of the business model using MVPs that may be worse than the final product (aka "validating MVPs").
Categories: Blogs

Knowledge Sharing

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