Skip to content

Feed aggregator

The 5 Stages Of A SaaS Bootstrapper’s Grief

Derick Bailey - new ThoughtStream - Thu, 07/10/2014 - 22:12

I’m nearly a year in to bootstrapping SignalLeaf. By most accounts, it is a successful podcast hosting service (unless you look at my P&L sheet – but I’m working on that). In the last 11 months, I’ve gone through a number of emotions regarding SignalLeaf – many of them in the same hour, day or week. And it occurred to me, just now, that a lot of the emotional turmoil that I’m facing as a solopreneur / entreprogrammer are directly mappable to the classic Kübler-Ross model of the 5 stages of grief.

So I give to you,

The 5 Stages of a SaaS Bootstrapper’s Grief

5 stages of bootstrapper grief

Stage 1: Denial (of the value that you provide)

Nope. It’s not going to happen. Ever.

Stage 1 denial

There’s no way anyone will ever use what I’ve built, let alone pay for it! Why would they? It’s so easy to do this on your own. I mean, I did it and it only took me a day to do it! But now I have to go and set up all this infrastructure to support accounts and logins and payments… seriously… Why would anyone ever pay for this?!

No. I’m done. I refuse. It will never happen.

Stage 2: Anger (at not getting customers)

DAMNIT!!! Why aren’t i getting any customers?!

Stage 2 anger

I’ve got EXACTLY what you need! I do it BETTER than they do, and I am so much more hands on in my support! What is wrong with you people?! Why do you sign up for them, instead of me? Why do you get a trial account with me and then LEAVE FOR THEM?! AAAAAARRRRRGGGGHHH!!!!!

WHY ME?! WHY AM I NOT GETTING ANY PAYING CUSTOMERS?! IT’S NOT FAIR!

Stage 3: Bargaining (with customers)

Ok, look. I just need one more customer. Please. Just one more customer.

Stage 3 bargaining

Just one this week. If I get one more customer, then I’ll know that this is real. Then I’ll be certain that what I’m doing is worth it. 

Yeah, I realize that you’re not signing up because you don’t know me – you don’t trust me, you don’t have an entire market share of people telling you how good I am. I know that. But I am worth it. In fact, I’ll prove to you that I’m worth it. I’ll not only give you a discount to start with, I’ll give you 1:1 assistance. I’ll give you more than the usual discount, too. I’ll wash your ceilings, comb your lawn and mow your windows… whatever it takes!

I’ll bend over backwards to get you to sign up and pay for my service. I know what my service can do for you and I’m willing to give you more than ask for if you try it out.  Just don’t leave me. What can I do to keep you, dear customer? Anything… please… just one more customer…

Stage 4: Depression (about your financial state)

I only have 16 customers?! #sniff … #sigh

Stage 4 depression

I’m spending $5x more per month than I’m earning. This sucks. It’s been almost a year, and I’m not making it yet. I just needed more paying customers… but nothing I try is working, and I don’t know why. Why bother? Why try? Why go on? My bank account is going to be dry soon. The SaaS will die. I’ll be bankrupt. Why go on?

I’m not going to work on it anymore. I’ll just let it die on it’s own. I’ll ignore it. It’s going to die anyways.

Stage 5: Acceptance (of the work to be done)

I know. You’re right. You were always right.

Stage 5 acceptance

I didn’t realize just how important marketing was. I didn’t take the lessons learned that you tried to teach me seriously. I didn’t listen. But I get it now. I do. And I’m willing to change. I’m willing to learn how to be a marketer as well as a developer. I’m willing to put in the time and effort.

I know that I have a lot of work to do, and I’m not just saying I’m going to do it. I’m actually doing it now. I’ve already started. I rolled up my sleeves this week, and set a plan in motion. It’s going to take a long time, I know that. It’s going to be hard work. I get it.

It’s going to be worth it. Because when I look at what I’ve already done – the 20 customers that are already paying me, and are saying such amazing things about what I’m doing for them – I KNOW the hard work will pay off. And I know how much work this is going to be.

So I’m here, now. I’ve got my work gloves on. I’ve got my sunscreen, my shovel and my determination. I will do the work. I will earn that customer the hard way, at first. I will improve my services, my marketing and my bottom line.

I will succeed.

     Related Stories 
Categories: Blogs

Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar

BigVisible Solutions :: An Agile Company - Thu, 07/10/2014 - 20:47

Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar by Dave Prior

When an organization makes the decision to move from a traditional (waterfall) approach to Agile, coming to grips with the new way of tracking projects can be one of the biggest challenges. Dave Prior presents on some of the tips and tools he has found to have a positive impact when helping an organization let go of their dependence on traditional project tracking in favor of Agile reporting.

Webinar Topics Include:
• Core differences between traditional and Agile project tracking
• How Agile reporting can impact a traditional organization
• Communication Modeling and Agile Transition
• Understanding the needs of an organization in transition
• Tracking Agile projects
• Hybrid reporting approaches

download

The post Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar appeared first on BigVisible Solutions.

Categories: Companies

Neo4j: LOAD CSV – Processing hidden arrays in your CSV documents

Mark Needham - Thu, 07/10/2014 - 16:54

I was recently asked how to process an ‘array’ of values inside a column in a CSV file using Neo4j’s LOAD CSV tool and although I initially thought this wouldn’t be possible as every cell is treated as a String, Michael showed me a way of working around this which I thought was pretty neat.

Let’s say we have a CSV file representing people and their friends. It might look like this:

name,friends
"Mark","Michael,Peter"
"Michael","Peter,Kenny"
"Kenny","Anders,Michael"

And what we want is to have the following nodes:

  • Mark
  • Michael
  • Peter
  • Kenny
  • Anders

And the following friends relationships:

  • Mark -> Michael
  • Mark -> Peter
  • Michael -> Peter
  • Michael -> Kenny
  • Kenny -> Anders
  • Kenny -> Michael

We’ll start by loading the CSV file and returning each row:

$ load csv with headers from "file:/Users/markneedham/Desktop/friends.csv" AS row RETURN row;
+------------------------------------------------+
| row                                            |
+------------------------------------------------+
| {name -> "Mark", friends -> "Michael,Peter"}   |
| {name -> "Michael", friends -> "Peter,Kenny"}  |
| {name -> "Kenny", friends -> "Anders,Michael"} |
+------------------------------------------------+
3 rows

As expected the ‘friends’ column is being treated as a String which means we can use the split function to get an array of people that we want to be friends with:

$ load csv with headers from "file:/Users/markneedham/Desktop/friends.csv" AS row RETURN row, split(row.friends, ",") AS friends;
+-----------------------------------------------------------------------+
| row                                            | friends              |
+-----------------------------------------------------------------------+
| {name -> "Mark", friends -> "Michael,Peter"}   | ["Michael","Peter"]  |
| {name -> "Michael", friends -> "Peter,Kenny"}  | ["Peter","Kenny"]    |
| {name -> "Kenny", friends -> "Anders,Michael"} | ["Anders","Michael"] |
+-----------------------------------------------------------------------+
3 rows

Now that we’ve got them as an array we can use UNWIND to get pairs of friends that we want to create:

$ load csv with headers from "file:/Users/markneedham/Desktop/friends.csv" AS row 
  WITH row, split(row.friends, ",") AS friends 
  UNWIND friends AS friend 
  RETURN row.name, friend;
+-----------------------+
| row.name  | friend    |
+-----------------------+
| "Mark"    | "Michael" |
| "Mark"    | "Peter"   |
| "Michael" | "Peter"   |
| "Michael" | "Kenny"   |
| "Kenny"   | "Anders"  |
| "Kenny"   | "Michael" |
+-----------------------+
6 rows

And now we’ll introduce some MERGE statements to create the appropriate nodes and relationships:

$ load csv with headers from "file:/Users/markneedham/Desktop/friends.csv" AS row 
  WITH row, split(row.friends, ",") AS friends 
  UNWIND friends AS friend  
  MERGE (p1:Person {name: row.name}) 
  MERGE (p2:Person {name: friend}) 
  MERGE (p1)-[:FRIENDS_WITH]->(p2);
+-------------------+
| No data returned. |
+-------------------+
Nodes created: 5
Relationships created: 6
Properties set: 5
Labels added: 5
373 ms

And now if we query the database to get back all the nodes + relationships…

$ match (p1:Person)-[r]->(p2) RETURN p1,r, p2;
+------------------------------------------------------------------------+
| p1                      | r                  | p2                      |
+------------------------------------------------------------------------+
| Node[0]{name:"Mark"}    | :FRIENDS_WITH[0]{} | Node[1]{name:"Michael"} |
| Node[0]{name:"Mark"}    | :FRIENDS_WITH[1]{} | Node[2]{name:"Peter"}   |
| Node[1]{name:"Michael"} | :FRIENDS_WITH[2]{} | Node[2]{name:"Peter"}   |
| Node[1]{name:"Michael"} | :FRIENDS_WITH[3]{} | Node[3]{name:"Kenny"}   |
| Node[3]{name:"Kenny"}   | :FRIENDS_WITH[4]{} | Node[4]{name:"Anders"}  |
| Node[3]{name:"Kenny"}   | :FRIENDS_WITH[5]{} | Node[1]{name:"Michael"} |
+------------------------------------------------------------------------+
6 rows

…you’ll see that we have everything.

If instead of a comma separated list of people we have a literal array in the cell…

name,friends
"Mark", "[Michael,Peter]"
"Michael", "[Peter,Kenny]"
"Kenny", "[Anders,Michael]"

…we’d need to tweak the part of the query which extracts our friends to strip off the first and last characters:

$ load csv with headers from "file:/Users/markneedham/Desktop/friendsa.csv" AS row 
  RETURN row, split(substring(row.friends, 1, length(row.friends) -2), ",") AS friends;
+-------------------------------------------------------------------------+
| row                                              | friends              |
+-------------------------------------------------------------------------+
| {name -> "Mark", friends -> "[Michael,Peter]"}   | ["Michael","Peter"]  |
| {name -> "Michael", friends -> "[Peter,Kenny]"}  | ["Peter","Kenny"]    |
| {name -> "Kenny", friends -> "[Anders,Michael]"} | ["Anders","Michael"] |
+-------------------------------------------------------------------------+
3 rows

And then if we put the whole query together we end up with this:

$ load csv with headers from "file:/Users/markneedham/Desktop/friendsa.csv" AS row 
  WITH row, split(substring(row.friends, 1, length(row.friends) -2), ",") AS friends 
  UNWIND friends AS friend  
  MERGE (p1:Person {name: row.name}) 
  MERGE (p2:Person {name: friend}) 
  MERGE (p1)-[:FRIENDS_WITH]->(p2);;
+-------------------+
| No data returned. |
+-------------------+
Nodes created: 5
Relationships created: 6
Properties set: 5
Labels added: 5
Categories: Blogs

The Heart Rate Monitor

Illustrated Agile - Len Lagestee - Thu, 07/10/2014 - 15:01

My desk where I’m currently coaching is surrounded by three Agile teams. Periodically, I’ll just watch and listen to each of them and before long, the heart beat of each team begins to reveal itself. Under “normal” conditions the teams will have a nice steady pulse. They have planned their work effectively, they are having fun, there is energy and excitement, and they are delivering results.

There are times however, when something changes and a noticeable increase or decrease in the pulse occurs. This can happen when a new team member arrives, impacting the  dynamics of the team. It can happen when priorities are refined, a significant impediment has been discovered, or it can happen when a manager interjects themselves into team ceremonies. Ever notice the reaction of most teams when delivery dates are mandated to an Agile team? Not pretty.

When the pulse of the team spikes or plunges significantly, the Scrum Master should recognize and react by becoming the team “heart rate monitor.” To explain this concept, here is an excerpt from my book Becoming a Catalyst: Scrum Master Edition. This comes from the chapter The Necessary Fuel where I talk about specific traits a Scrum Master should develop and this text comes from the “Process Conscience” trait.

Well-functioning teams should have a wonderful cadence about them. You can almost hear and see the heartbeat. There is a natural buzz of sustainable energy and pace and hopefully through the Intense Observer trait you have heard and felt what this is like. To be the conscience of the team, the Catalyst finds a natural pace for the team and becomes keeper of the beat. The Catalyst ensures a steady rhythm and an almost comforting flow. I often use the analogy of walking or jogging on a treadmill to describe this.

When you first get on a treadmill, you usually start slowly and gradually increase the speed or incline. Depending on your physical conditioning, if you go too fast or too high too quickly, your heart rate elevates. Stay at this level too long and the incline or speed must be reduced. If your heartbeat remains too low, the benefits of being on the treadmill have been diminished.

Catalysts use a methodology or process to act as the heart rate monitor for the team. They can assess the ideal level of exertion a team should have and strive to keep team members there. With a new team (when the level of team “conditioning” is not yet high), the team operates at a slower cadence while getting used to the methodology, technology, and working with each other. The amount of work the team takes on should be reduced until team members are comfortable with the process and can work up to their optimal heartbeat. Even after a team has been together for a while, reducing the amount of work a team commits too is not easy. Most teams are overly optimistic. It will take a strong conscience to keep them from harming themselves.”

This doesn’t mean there are times when the heart rate should become elevated. Preparing for a major release for example or when the vision of the organization is naturally pulling the team to deliver valuable features. Just like the human body, we just can’t stay there forever or we will burn-out or crash. This is the sustainable pace documented in the Agile Principles.

When you get a sense of the heartbeat of your team you can begin to understand when it is ok for the heart rate to be elevated or when the team is actually stressed by overwork and exhaustion. If the team doesn’t have time to catch their breath, this stress will build to the point of fracture. People will no longer believe “being Agile” is possible and the Agile principles are just words on a screen.

For many Scrum Masters, an approach for determining the heart rate for their team is by determining the velocity for the team and using a burn-down chart. From this chart, if used appropriately, the team health story is revealed. There are also issues with the burn-down chart and I’ll cover that next week.

Take a minute and recognize the heart rate of your team. Watch and listen intently. Are they under stress? Is there a natural hum of energy, movement, and excitement? Everything you need to know about the health and vibrancy of a team can be gleaned from a period of observation.

Becoming a Catalyst - Scrum Master Edition

The post The Heart Rate Monitor appeared first on Illustrated Agile.

Categories: Blogs

Five links on Agile Testing

…if you are not defining your tests at the acceptance level before you are writing your code you are creating waste.

@alshalloway

henrik.signature

 

 

 

I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!

Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.


Categories: Blogs

.NET in SonarQube: bright future

Sonar - Thu, 07/10/2014 - 11:12

A few months ago, we started on an innocuous-seeming task: make the .NET Ecosystem compatible with the multi-language feature in SonarQube 4.2. What followed was a bit like one of those cartoons where you pull a string on the character’s sweater and the whole cartoon character starts to unravel. Oops.

Once we stopped pulling the string and started knitting again (to torture a metaphor), what came off the needles was a different sweater than what we’d started with. The changes we made along the way – fewer external tools, simpler configuration – were well-intentioned, and we still believe they were the right things to do. But many people were at pains to tell us that the old way had been just fine, thank you. It had gotten the job done on a day-to-day basis for hundreds of projects, and hundreds-of-thousands of lines of code, they said. It had been crafted by .NETers for .NETers, and as Java geeks, they said, we really didn’t understand the domain.

And they were right. But when we started, we didn’t understand how much we didn’t understand. Fortunately, we have a better handle on our ignorance now, and a plan for overcoming it and emerging with industry leading C# and VB.NET analysis tools.

First, we’re planning to hire a C# developer. This person will be first and foremost our “really get .NET” person, and represents a real commitment to the future of SonarQube’s .NET plugins. She or he will be able to head off our most boneheaded notions at the pass, and guide us in the ways of righteousness. Or at least in the ways of .NETness.

Of course it’s not just a guru position. We’ll call on this person to help us progressively improve and evolve the C# and VB.NET plugins, and their associated helpers, such as the Analysis Bootstrapper. He (or she) will also help us fill the gaps back in. When we reworked the .NET ecosystem there were gains, but there were also loses. For instance, there are corner cases not covered today by the C# and VB.NET plugins which were covered with the old .NET Ecosystem.

We also plan to start moving these plugins into C#. We’ve realized that just can’t do the job as well in Java as we need to. But the move to C# code will be a gradual one, and we’ll do our best to make it painless and transparent. Also on the list will be identifying the most valuable rules from FxCop and ReSharper and re-implementing them in our code.

At the same time, we’ll be advancing on these fronts for both C# and VB.NET:

  • Push “cartography” information to SonarQube.
  • Implement bug detection rules.
  • Implement framework-specific rules, for things like SharePoint.

All of that with the ultimate goal of becoming the leader in analyzing .NET code. We’ve got a long way to go, but we know we’ll bring it home in the end.

Categories: Open Source

More Agile Testing: Book Review

Growing Agile - Thu, 07/10/2014 - 11:00

We were lucky enough to receive a pre-release copy of Janet Gregory and Lisa Crispin’s new book: More Agile Testing. The book is available for pre-order and the published version is coming soon. I highly recommend the book, even if you haven’t read the previous one. Here’s my review.

 Book ReviewMore Agile Testing is a great collection of stories and ideas that can help you improve, not just how you test, but the products you build and the way you work. What I love most about the book is how easy many of the ideas are to try. If one message is clear, it is that regardless of your context and challenges there are things you can try to improve. Get started today with something small, and nothing will be impossible.

I wanted to pick three things that I found most useful to share with potential readers to help you get a flavour for the book. Trust me it was hard to pick just three, but here they are.

The chapter on Technical Awareness is excellent. For a long time I have heard people debate whether testers need to be able to code. In this chapterJanet and Lisa answer this eloquently and confirm my personal views that even if you don’t write code, testing requires specific and deep technical skills.

Secondly I love the approach to both Session Based and Thread Based Exploratory Testing with test charters. In particular the idea of using this with the whole team for pre-release manual regression. I have been struggling to find a good approach for teams not ready or able to give up manual regression and I think this approach is exactly what I have been searching for.

The third (and hardest to pick because the more I read, the more good ideas there were) is the approach of using page objects to simply automated UI testing. I often encounter teams stalled in the maintenance nightmare of GUI automation and I have not had practical advice except move the tests down the pyramid. This books offers some great ideas to help refactor and structure UI tests.

Lisa and Janet mention this book starts where the last one left off, but in someways I think it’s a great prequel. If you read agile testing and haven’t managed to adopt the ideas in it, then I think this book will help you get started. The stories in the book will help you see that even seemingly impossible obstacles can be overcome. Probably the greatest praise I can give this book is to say that it made me want to become a tester again. It is an exciting time with fantastic tools and approaches available and this book will help you uncover them.

Categories: Companies

XM Principle 10: Partner Patterns

Scrum Breakfast - Thu, 07/10/2014 - 09:00
Deliveries often rely on third party suppliers, and often they are not yet able to deliver a new product that meets our new specification within a single sprint. So what can we do in order to go from an idea to a new product or service in a customer’s hands in less than 7 days?

WIKISPEED first designs a wrapper, usually a plate of aluminum with pre-defined bolt patterns, around the third party supplied part to create a known “interface” that won’t change, even if that third party part changes. You might see how this is enforced by principle 2: Object-Oriented, Modular Architecture and 4: Contract-First Design, and then sped up by principle 6: Agile Hardware Design Patterns.

Once each third party part is wrapped in a known interface, you can iterate between suppliers and in-house prototypes or volume parts at very low cost. The only marginal cost is that of changing the wrapper itself.

Then, to expedite suppliers, ask them to deliver a certain set of performance characteristics as opposed to an engineering specification. "Do you have a transmission suitable for 100hp motor?", not "Here is our design for a transmission, can you build it?" Why should you wait months for a supplier to build a device to your specifications when they have a device that will satisfy your needs already in the catalog or in stock?

Many engineers are quick to design their own solution, which works to the team’s advantage when the design team is also the volume manufacturing team. But in cases where some production is outsourced, sending a list of values and tests to the outsourced vendor and not sending an engineering specification gives the supplier the most room to innovate. This allows the vendor to do what they do best, that part, which is why you are partnering with them in the first place. Team WIKISPEED finds they get higher quality parts faster, often from within the vendor’s existing stock.

The 10 Principles of Extreme Manufacturing
Categories: Blogs

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

New ScrumMaster Tips

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

Team

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

Random Issues in the Agile Transformation Bridge

BigVisible Solutions :: An Agile Company - Wed, 07/09/2014 - 17: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

Tacoma-narrows-bridge-collapse

  • 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

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:

TauLibrary

#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

Knowledge Sharing


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