Feed aggregator

### The Impact of Agile and Lean Startup on Project Portfolio Management

Agile Management Blog - VersionOne - Wed, 08/20/2014 - 13:55

With the large number of organizations now adopting agile methods, the existing body of literature has paid significant attention to the function of project management, business analysis, and more recently program management.  This is understandable as individuals filling these roles are ubiquitous and critical to the operation of their respective organizations.

Many organizations have an additional formalized function, project portfolio management (PPM), that is also critical to the organization but gets little attention — especially in light of the considerable desire being shown to scaling agile to the enterprise level.  The focus, objectives, and responsibilities of agile PPM must fundamentally shift when transitioning to an agile model, structure, and culture.  The reason for this is simple—the same agile principles that are being applied to individual projects can also be leveraged to manage the portfolio.

Below are two ways that agile PPM differs from traditional PPM:

Traditional PPM:  Optimize portfolio resources (individuals) by skill set
Agile PPM:  Maximize value delivery to customers by team capability

Traditional projects, while still delivered by teams, are much more focused on optimizing skill set across a portfolio.  One reason for this is because most traditional organizations are structured and organized by functional specialty.  That is, the organization’s structure is very hierarchical and often has individuals within a particular functional specialty (business analysis, quality assurance, project management, etc.) reporting to the same manager.

Another reason is that projects move through the process by passing through one of several phase gates such as requirements, design, test, etc.  When this is the case, project execution may be throttled by a particular skill set at each gate.  For example, if you have five business analysts, you will be limited to the number of projects that can be active.  However, most organizations ignore this fact and still have far too many projects active at any time; this only adds needless risk.  The sad truth is that most organizations really have no idea of their true project capacity.

In agile organizations, the team (not the individual) is the unit of capacity measure.  Therefore, if you have three teams that are capable of delivering an initiative or feature, you are limited by the number of teams.  So, how many projects of each type can you have active at any one time?  I don’t know; each situation will vary by organization, team, and context.  However, to get started, try setting the limit to be equal to the number of teams with the capability of delivering that type of solution.  If it doesn’t help, experiment.

For example, if you have five products that need mobile solutions, but only have three teams capable of doing the work, only start the three that will deliver the highest customer value.  Of course, that assumes that the teams are not already working on other items.

Traditional PPM:  Maximize Revenue and Evaluate Project Health
Agile PPM:  Govern Empirically through Validated Learning

One of the primary goals of traditional PPM is maximizing revenue… that is, how much money a particular project or product can add to the “bottom line” of a company’s balance sheet.  In today’s economy that is characterized by pervasive, disruptive technology and consumers that demand choice and flexibility focusing on revenue alone misses the point.

Revenue is the metric of wildly satisfied customers.

Stated another way, many would say that the sole objective of PPM is to maximize shareholder value.  This is done through increasing revenue, but it misses the point.  Because customers have flexibility and plentiful choices, the focus must be on maximizing customer value.  By focusing on customer value, if shareholder value doesn’t increase, it may be because you’re building the wrong thing.  Wouldn’t it be appealing to find that out sooner rather than later?

Further, traditional PPM typically measures the health of the agile portfolio by evaluating the health of its component projects.  This is great—in theory.  But one of the big problems with this approach is the way in which health is typically measured.  It’s most commonly done through subjective mechanisms like project status reports, achieved milestones, and progress stoplight indicators.  None of these approaches offer an objective mechanism of determining if the project is actually building the right thing.  Personally, I’ve managed projects that have delivered the wrong solution on time and within budget.  The kind of objectivity that’s required is customer validation.

A more agile PPM approach would be to introduce some mechanism of validated learning to help us make more sound and responsible decisions for our customers about what projects or products to continue funding.  Validated learning is a key aspect of the Lean Startup approach made popular by Eric Ries’ book of the same name.  Agile projects aim to build small increments of a product.  This means we are dealing with smaller return-on-investment (ROI) horizons.

Through agile PPM it’s possible to incrementally fund two projects to experiment with two different solutions to a (perceived) customer problem.  This is known as A/B testing, a.k.a., “split testing.”  Because agile methods allow us to get solutions into the hands of customers more quickly, we can evaluate the results of our experiments and shift funding to investments that are more promising and pertinent.  Because the funding is done incrementally, we need not fund an entire project for an extended period before finding out whether our assumptions were incorrect.

Summary

While these are only two of many considerations when adopting agile PPM, each has the potential to make an immediate and lasting impact on your organization and its customers, thereby, positively impacting your shareholders as well.  In my opinion, the sooner organizations can sow the seeds of customer satisfaction through validated learning, engagement, and collaboration, the sooner they will reap the rewards of increased shareholder value.

What are your thoughts?  How can you begin to apply these concepts within your own unique context?

Categories: Companies

### Using Card Types to Manage Your Work More Effectively

In LeanKit, teams can customize their card types to match the nature of their work. Card types for a software development team might include user stories, defects, features, and improvements. For an IT Operations team, they could be desktop support, server support, maintenance, and implementation. LeanKit lets you define your own card types as colors or icons, […]

The post Using Card Types to Manage Your Work More Effectively appeared first on Blog | LeanKit.

Categories: Companies

### Enterprise Lean Startup Webinar Series: Metrics and Analytics to Support Innovation and Learning

BigVisible Solutions :: An Agile Company - Tue, 08/19/2014 - 20:13

Join us for the next installment of our Enterprise Lean Startup Webinar series: ” Metrics and Analytics to Support Innovation and Learning”. Evan Campbell will introduce several of the measurement frameworks commonly used to define the critical levers to your business success, and methods for validating changes to your product through observed changes in usage. […]

Categories: Companies

### Lean, Agile & Scrum Conference, Zurich, Switzerland, September 9 2014

Scrum Expert - Tue, 08/19/2014 - 19:52
The Zurich Lean, Agile & Scrum Conference (LAS) is a one day conference that focuses on Lean and Agile approaches for software development. The conference provides both German and English content. The keynotes of the 2014 edition of the Zurich Lean, Agile & Scrum Conference will be Alistair Cockburn and Bob Marshall. In the agenda you can find topics like “Our journey from Waterfall to Agile; Delivering an Agile Framework to a Global IT Organization”, “Transforming Addicted Organisations (Serenity to Accept What I Cannot Change, Courage to Change What I Can)” ...
Categories: Communities

### Creating a Company Where Everyone Gives Their Best

J.D. Meier's Blog - Tue, 08/19/2014 - 18:50

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.” —Steve Jobs

What does it take to create a company where everybody gives their best where they have their best to give?

It takes empathy.

It also takes encouraging people to be zestful, zany, and zealous.

It takes bridging the gap between the traits that make people come alive, and the traits that traditional management practices value.

In the book The Future of Management, Gary Hamel walks through what it takes to create a company where everyone gives their best so that employees thrive and companies create sustainable competitive advantage.

Resilience and Creativity: The Traits that Differentiate Human Beings from Other Species

Resilience and creativity are what separate us from the pack.

“Ask your colleagues to describe the distinguishing characteristics of your company, and few are likely to mention adaptability and inventiveness.  Yet if you ask them to make a list of the traits that differentiate human beings from other species, resilience and creativity will be near the top of the list.  We see evidence of these qualities every day -- in ourselves and in those around us. “

We Work for Organizations that Aren't Very Human

People are adaptive and creative, but they often work for organizations that are not.

“All of us know folks who've switched careers in search of new challenges or a more balanced life.  We know people who've changed their consumption habits for the sake of the planet.  We have friends and relatives who've undergone a spiritual transformation, or risen to the demands of parenthood, or overcome tragedy.  Every day we meet people who write blogs, experiment with new recipes, mix up dance tunes, or customize their cars.  As human beings, we are amazingly adaptable and creative, yet most of us work for companies that are not.  In other words, we work for organizations that aren't very human.”

Modern Organizations Deplete Natural Resilience and Creativity

Why do so many organizations underperform?  They ignore or devalue the capabilities that make us human.

“There seems to be something in modern organizations that depletes the natural resilience and creativity of human beings, something that literally leaches these qualities out of employees during daylight hours.  The culprit?  Management principles and processes that foster discipline, punctuality, economy, rationality, and order, yet place little value on artistry, nonconformity, originality, audacity, and élan.  To put it simply, most companies are only fractionally human because they make room for only a fraction of the qualities and capabilities that make us human.  Billions of people show up for work every day, but way too many of them are sleepwalking.  The result: organizations that systematically underperform their potential.”

Adaptability and Innovation Have Become the Keys to Competitive Success

There’s a great big gap between what makes people great and the management systems that get in the way.

“Weirdly, many of those who labor in the corporate world--from lowly admins to high powered CEOs--seem resigned to this state of affairs.  They seem unperturbed by the confounding contrast between the essential nature of human beings and the essential nature of the organization in which they work.  In years past, it might have been possible to ignore this incongruity, but no longer--not in a world where adaptability and innovation have become the sine qua non of competitive success.  The challenge: to reinvent our management systems so they inspire human beings to bring all of their capabilities to work every day.”

The Human Capabilities that Contribute to Competitive Success

Hamel offers his take on what the relative contribution of human capabilities that contribute to value creation, recognizing that we now live in a world where efficiency and discipline are table stakes.

Passion 35% Creativity 25% Initiative 20% Intellect 15% Diligence 5% Obedience 0%   100%

“The human capabilities that contribute to competitive success can be arrayed in a hierarchy.  At the bottom is obedience--an ability to take direction and follow rules.   This is the baseline.  Next up the ladder is diligence.  Diligent employees are accountable.  They don't take shortcuts.  They are conscientious and well-organized.  Knowledge and intellect are on the next step.  Most companies work hard to hire intellectually gifted employees.  They value smart people who are eager to improve their skills and willing to borrow best practices from others.  Beyond intellect lies initiative.  People with initiative don't wait to be asked and don't wait to be told.  They seek out new challenges and are always searching for new ways to add value.  Higher still lies the gift of creativity.  Creative people are inquisitive and irrepressible.  They're not afraid of saying stupid things.  They start a lot of conversations with, 'Wouldn't it be cool if ..." And finally, at the top lies passion.”

The Power of Passion

Passion makes us do dumb things.  But it’s also the key to doing great things.

Via Via The Future of Management:

“Passion can make people do stupid things, but it's the secret sauce that turns intent into accomplishment.  People with passion climb over obstacles and refuse to give up.  Passion is contagious and turns one-person crusades into mass movements.  As the English novelist E.M. Forster put it, 'One person with passion is better than forty people merely interested.'”

Obedience is Worth Zip in Terms of Competitive Advantage

“I'm not suggesting that obedience is literally worth nothing.  A company where no one followed any rules would soon descend into anarchy.  Instead, I'm arguing that rule-following employees are worth zip in terms of their competitive advantage they generate.  In a world with 4 billion nearly distributed souls, all eager to climb the ladder of economic progress, it's not hard to find billable, hardworking employees.  And what about intelligence?  For years we've been told we're living in the knowledge economy; but as knowledge itself becomes commoditized, it will lose much of its power to create competitive advantage.”

Obedience, Diligence, and Expertise Can Be Bought for Next to Nothing

You can easily buy obedience, diligence, and expertise from around the world.

But that’s not what will make you the next great company or the next great thing or a great place to work.

“Today, obedience, diligence, and expertise can be bought for next to nothing.  From Bangalore to Guangzhou, they have become global commodities.  A simple example: turn over your iPod, and you'll find six words engraved on the back that foretell the future of competition: 'Designed in California. Made in China.'  Despite the equal billing, the remarkable success of Apple's music business owes relatively little to the company's network of Asian subcontractors.  It is a credit instead to the imagination of Apple's designers, marketers, and lawyers.  Obviously not every iconic product is going to be designed in California, not nor manufactured in China. “

You Need Employees that are Zestful, Zany, and Zealous

If you want to bring out the best in people and what they are capable of, aim for zestful, zany, and zealous.

“The point, though, is this: if you want to capture the economic high ground in the creative economy, you need employees who are more than acquiescent, attentive, and astute--they must also be zestful, zany, and zealous.”

If you want to bring out your best, then break our your zest and get your zane on.

You Might Also Like

The Principles of Modern Management

How Employees Lost Empathy for their Work, for the Customer, and for the Final Product

No Slack = No Innovation

The Drag of Old Mental Models on Innovation and Change

The New Competitive Landscape

The New Realities that Call for New Organizational and Management Capabilities

Categories: Blogs

### Agile 2014 – speaking and attending; a summary

Xebia Blog - Tue, 08/19/2014 - 18:14

So Agile 2014 is over again… and what an interesting conference it was.

What did I find most rewarding? Meeting so many agile people! My first conclusion was that there were experts like us agile consultants or starting agile coaches, ScrumMasters and other people getting acquainted with our cool agile world. Another trend I noticed was the scaled agile movement. Everybody seems to be involved in that somehow. Some more successful than others; some more true to agile than others.

What I missed this year was the movement of scrum or agile outside IT although my talk about scrum for marketing had a lot of positive responses.  Everybody I talked to was interested in hearing more information about it.

There was a talk maybe even two about hardware agile but I did not found a lot of buzz around it. Maybe next year? I do feel that there is potential here. I believe Fullstack product development should be the future. Marketing and IT teams? Hardware and software teams?  Splitting these still sounds as design and developer teams to me.

But what a great conference it was. I met a lot of awesome people. Some just entering the agile world; some authors of books I had read which got me further in the agile movement. I talked to the guys from Spotify. The company which is unique in its agile adoption / maturity. And they don’t even think that they are there yet. But then again will somebody ever truly BE agile ..?

I met the guys from scrum.inc who developed a great new scaled framework. Awesome ideas on that subject and awesome potential to treat it as a community created open framework; keep your eyes open for that!

I attended some nice talks too; also some horrible ones. Or actually 1, which should never have been presented in a 90 minute slot in a conference like this. But lets get back to the nice stories. Lyssa Adkins had a ‘talk’ about conflicts. Fun thing was that she actually facilitated the debate about scaled agile on stage. The session could have been better but the idea and potential of the subject is great.

Best session? Well probably the spotify guys. Still the greatest story out there of an agile company. The key take-out of that session for me is: agile is not an end-state, but a journey. And if you take it as serious as Spotify you might be able to make the working world a lot better. Looking at Xebia we might not even be considered to be trying agile compared to them. And that is meant in a humble way while looking up to these guys! - I know we are one of the frontiers of agile in the Netherlands. The greatest question in this session: ‘Where is the PMO in your model….’

Well you clearly understand this …

Another inspiring session was the keynote session from the CFO of Statoil about beyond budgeting. This was a good story which should become bigger in the near future as this is one of the main questions I get when implementing agile in a company: “how do we plan / estimate and budget projects when we go and do agile?” Beyond budgeting at least get’s us a little closer.
Long story short. I had a blast in Orlando. I learnt new things and met a lot of cool people.My main take out: Our community is growing which teaches us that we are not yet there by a long run. An awesome future is ahead! See you next year!

Categories: Companies

### Scaled Agile Framework (SAFe) 3.0 Released

Scrum Expert - Tue, 08/19/2014 - 17:43
The version 3.0 of the Scaled agile Framework (SAFe) has been released. The Scaled agile Framework is a methodology created by Dean Leffingwell to implement Agile practices at enterprise scale. Major changes in the SAFe 3.0 version include: * Guidance on the critical role, knowledge and responsibilities of Lean-Agile Leadership * Enhanced Portfolio Level — new flow, new Metrics, Strategic Themes that connect business strategy to Portfolio Vision, and Portfolio-level Non-functional Requirements (NFRs) * Lean-Agile Budgeting optimized for flow “Beyond Project Cost Accounting” * New guidance on Coordinating multiple Agile Release Trains within larger Value ...
Categories: Communities

Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach.  Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony.  This is my other trick.

Requirements for team estimation (and planning):
• Product Owner
• The whole Development Team (i.e. everyone who will be involved in doing the work)
• Product Backlog
• Definition of “Done”
When team membership changes:

A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.

When team member allocation is adjusted:

Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.

Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.

WARNING:

The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.

Step 1 – What is our current velocity?

After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!

Step 2 – What is our current capacity?

As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:

50%        Chris P. Codemuncher

50%        Larry Legassifulunch

25%        Beth Breaksidal

The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 25% = 2.13 days    Beth Breaksidal

8.5 x 40% = 3.4 days      Gertrude Gamesthadox

8.5 x 40% = 3.4 days      Dana Deadlinedryver

17.43                              Total combined available days per Sprint

Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:

21            Velocity

17            Capacity

21/17       V/C

(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)

Step 3 – How much capacity do we hope to have in the next Sprint?

Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”

Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…

But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 15% = 1.28 days     Dana Deadlinedryver

16.58                               Total combined ACTUAL available days in Sprint 1

16                                    Actual capacity (rounded-down)

21/16                               Actual V/C

As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.

Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:

8.5 x 100% = 8.5 days     Sally Supaspeshalis

8.5 x 100% = 8.5 days     Chris P. Codemuncher

8.5 x 75% = 6.38 days     Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 0% = 0 days            Dana Deadlinedryver

(Note: Dana is also the Scrum Master with plenty of other work to do for the team)

30.18                               Total combined hoped-for available days in Sprint 1

30                                     Hoped-for capacity (rounded-down)

Step 4 – How much velocity do we hope to have in the next Sprint?

21            Actual Historical Velocity

16            Actual Historical Capacity

30            Hoped-For Future Capacity

x              Hoped-For Future Velocity

Some simple math, loaded with assumptions:

Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity

Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375

39            Hoped-For Future Velocity

Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?

Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.

Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!

See you next time,

Travis.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just 500 for a team to get targeted advice and great how-to informationPlease share! Categories: Blogs ### Software Waste is Invisible Agile Tools - Tue, 08/19/2014 - 15:34 You know what one of the biggest problems with knowledge work is? It’s mostly invisible. We can talk about it, but we can’t see it. You can’t see the stuff you want to create (except perhaps in your own head, which really doesn’t count) and perhaps most importantly you can’t see the stuff that is missing. It gets worse the more people you add to the equation. That’s right, go to a planning meeting and you will find a long list of things that the team thinks they want to do (struggling to make the work visible), but I can almost guarantee you there is no list of what is missing. Why not? Because we can’t see it. It’s hard enough to see the work – that’s tough enough to begin with, but you can just forget about seeing the delay that is associated with that work. I was reading Reinertson’s book on Product Development Flow the other day and within a couple of pages, it hit me: we can’t see what the hell we are trying to do – and that makes knowledge work really hard. We are like blind men trying to describe the proverbial elephant. If I were assembling a bicycle, I would be able to see all the parts before I put them together. I might even have some sort of inventory list to check against. I can physically see and verify the parts and the work that needs to be done. Compared to knowledge work, this physical assembly is worlds easier to estimate and accomplish – simply because we can see it. OK, to you this may be a big, “Duh!” moment. Fair enough. But here is where I realize that we may often have a problem. What is the output of a planning meeting? Some user stories, some tasks, maybe a few follow up questions? Perhaps a calendar or timeline of some sort? How often do you see a list of all the risks or potential delays that need to be addressed as an output of a planning meeting? Yeah, never. You see any process can be broken down into work and delay. This is the foundation for value streams. The thing is, you can’t have one and not the other. There is always delay in any system, no matter how efficient it is. But delay is one of the most neglected things we plan for. Honestly, most of the time we don’t plan for it. We plan the work and choose to ignore the delay. This is like talking about the work, but not acknowledging the impediments to the work. You can’t have one without the other. So why in the world would you NOT plan for delay? Planning for it is simply acknowledging that it’s real. Well, I would submit that part of the reason that delay doesn’t get more consideration is because it’s invisible. It’s very hard for us to see and visualize. Let’s face it, human beings perception of time is a total mess. We suck at assessing duration, so why would we be any good at assessing delay? On agile teams we have evolved mechanisms to make the work visible: Story boards, Kanban boards, & Story maps, are just some of the techniques that have evolved to make work visible to us. We need similar mechanisms to make delay, impediments and other forms of waste visible too. Once we do that, we will have a more realistic vision of the work we are trying to do. Filed under: Uncategorized Categories: Blogs ### Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking? Scrum 4 You - Tue, 08/19/2014 - 07:30 Mit der Reihe “Design Thinking für Product Owner” wollen wir Product Owner Anhaltspunkte dafür geben, wie sie ihr Produkt gestalten können und wie sie die Items für das Product Backlog generieren können. Warum ist Design Thinking für Product Owner wichtig? Der Product Owner ist für den Return on Investment verantwortlich, er bestimmt die Eigenschaften des Produkts, priorisiert nach Business-Value und kommuniziert eine klare Produktvision. Aber was der Nutzer wirklich braucht und wie aus vagen Produktideen eine klare Produktvision wird, beantwortet Scrum nicht! Genau hier kann Design Thinking den Product Owner unterstützen. In Iterationen nähert man sich der bestmöglichen Lösung für den Nutzer, generiert Wissen für sich und andere und kann schlussendlich dem Kunden und dem eigenen Scrum-Team eine getestete und erfolgversprechende Produktvision im Spannungsfeld aus Wünschbarkeit, Machbarkeit und Wirtschaftlichkeit präsentieren. Design Thinking behält dabei stets die Menschen, die das Produkt benutzen sollen, im Fokus und strebt danach, die Erfahrung des Nutzers mit der kreierten Lösung zu verbessern. Was ist eigentlich Design Thinking? Viele Menschen sehen auf den ersten Blick nur den Design-Thinking-Prozess, im Grunde ist Design Thinking aber eine agile Grundhaltung und eine Sammlung verschiedener Techniken aus unterschiedlichen Disziplinen. In der Kombination soll dies die Erfolgswahrscheinlichkeit bei der Entwicklung von Lösungen in komplexen Umfeldern erhöhen. Die Entwicklung von Ideen im moderierten Design-Thinking-Prozess ist dabei absolut nutzerfokussiert, ergebnisoffen und doch ergebnisorientiert. Das interdisziplinäre Team sucht nach aktuell unbefriedigten menschlichen Bedürfnissen, die dann im Mittelpunkt der Lösungsfindung stehen. Mitte der 1990er-Jahre wurde an der Fakultät für Ingenieurwesen der Universität Stanford der Name “Design Thinking” für dieses methodische Gerüst der Innovationsarbeit geprägt und in der 1991 gegründeten Innovations-Agentur IDEO bereits angewendet. In Europa wird diese Methode heute an der School of Design Thinking des Hasso-Plattner-Instituts in Potsdam … nun, nicht gerade gelehrt … eher erfahrbar gemacht. Was heißt “agiles Mindset”? Die wichtigsten Komponenten sind das Team, der Raum und der Prozess, aber ohne die passende persönliche Einstellung funktioniert Design Thinking nicht. Design Thinking braucht “T-shaped People”! Eine Bezeichnung für Menschen, die eine Tiefe/Spezialisierung in ihren Skills (vertikaler Balken) aufweisen, aber dennoch in der Lage sind, über Ihre Disziplin hinaus (horizontaler Balken) mit anderen Experten und Perspektiven zusammen zu arbeiten, zu teilen und zu wachsen. Der Design-Thinker sollte mit Unvorhersehbarkeit und Unsicherheit umgehen können. Positiv formuliert: Es bedarf einer mutigen, neugierigen und ergebnisoffenen Grundhaltung, denn der Design-Thinker kennt zu Beginn die Lösung nicht und wird erst im Laufe des Prozesses zum Experten. Er provoziert das Scheitern und setzt sich dem gnadenlosen Feedback der Nutzer aus … und das tut weh! Aber es ist auch der Auftakt zu neuen Erkenntnissen und – da man stets im Team arbeitet – zum gemeinsamen Lernen. All dies sollte der Design-Thinker wirklich wollen, verordnen kann man es nicht. In den folgenden Beiträgen zu “Design Thinking für Product Owner” werde ich Design Thinking näher erklären und aufzeigen, wie es mit Scrum kombinierbar ist. Ich freue mich über Fragen, Anregungen und Diskussionen! Related posts: Categories: Blogs ### Why is Data Sooo Messy and How to Avoid Data Landfills Categories: Blogs ### How to choose the right project? Decision making frameworks for software organizations Software Development Today - Vasco Duarte - Tue, 08/19/2014 - 05:00 Frameworks to choose the best projects in organizations are a dime a dozen. We have our NPV (net present value), we have our customized Criteria Matrix, we have Strategic alignment, we have Risk/Value scoring, and the list goes on and on. In every organization there will a preference for one of these or similar methods to choose where to invest people’s precious time and money. Are all these frameworks good? No, but they aren’t bad either. They all have some potential positive impact, at least when it comes to reflection. They help executive teams reflect on where they want to take their organizations, and how each potential project will help (or hinder) those objectives. So far, so good. “Everybody’s got a plan, until they get punched in the face” ~Tyson Surviving wrong decisions made with perfect data However, reality is seldom as structured and predictable as the plans make it out to be. Despite the obvious value that the frameworks above have for decision making, they can’t be perfect because they lack one crucial aspect of reality: feedback. Models lack on critical property of reality: feedback. As soon as we start executing a particular project, we have chosen a path and have made allocation of people’s time and money. That, in turn, sets in motion a series of other decisions: we may hire some people, we may subcontract part of the project, etc. All of these subsequent decisions will have even further impacts as the projects go on, and they may lead to even more decisions being made. Each of these decisions will also have an impact on the outcome of the chosen projects, as well as on other sub-decisions for each project. Perhaps the simplest example being the conflicts that arise from certain tasks for different projects having to be executed by the same people (shared skills or knowledge). And at this point we have to ask: even assuming that we had perfect data when we chose the project based on one of the frameworks above, how do we make sure that we are still working on the most important and valuable projects for our organization? Independently from the decisions made in the past, how do we ensure we are working on the most important work today? The feedback bytes back This illustrates one of the most common problems with decision making frameworks: their static nature. They are about making decisions "now", not "continuously". Decision making frameworks are great at the time when you need to make a decision, but once the wheels are in motion, you will need to adapt. You will need to understand and harness the feedback of your decisions and change what is needed to make sure you are still focusing on the most valuable work for your organization. All decision frameworks have one critical shortcoming: they are static by design. How do we improve decision making after the fact? First, we must understand that any work that is “in flight” (aka in progress) in IT projects has a value of zero, i.e., in IT projects no work has value until it is in use by someone, somewhere. And at that point it has both value (the benefit) and cost (how much we spend maintaining that functionality). This dynamic means that even if you have chosen the right project to start with, you have to make sure that you can stop any project, at any time. Otherwise you will have committed to invest more time and more money (by making irreversible “big bang” decisions) into projects that may prove to be much less valuable than you expected when you started them. This phenomenon of continuing to invest beyond the project benefit/cost trade-off point is known as Sunk Cost Fallacy and is a very common problem in software organizations: because reversing a decision made using a trustworthy process is very difficult, both practically (stop project = loose all value) and due to bureaucracy (how do we prove that the decision to stop is better than the decision to start the project?) Can we treat the Sunk Cost Fallacy syndrome? While using the decision frameworks listed above (or others), don’t forget that the most important decision you can make is to keep your options open in a way that allows you to stop work on projects that prove less valuable than expected, and to invest more in projects that prove more valuable than expected. In my own practice this is one of the reasons why I focus on one of the #NoEstimates rules: Always know what is the most valuable thing to work on, and work only on that. So my suggestion is: even when you score projects and make decisions on those scores, always keep in mind that you may be wrong. So, invest in small increments into the projects you believe are valuable, but be ready to reassess and stop investing if those projects prove less valuable than other projects that will become relevant later on. The #NoEstimates approach I use allows me to do this at three levels: • a) Portfolio level: by reviewing constant progress in each project and assess value delivered. As well as constantly preparing to stop each project by releasing regularly to a production-like environment. Portfolio flexibility. • b) Project level: by separating each piece of value (User Story or Feature) into an independent work package that can be delivered independently from all other project work. Scope flexibility. • c) User Story / Feature level: by keeping User Stories and Features as small as possible (1 day for User Stories, 1-2 weeks for Features), and releasing them independently at fixed time intervals. Work item flexibility Do you want to know more about adaptive decision frameworks? Woody Zuill and myself will be hosting a workshop in Helsinki to present our #NoEstimates ideas and to discuss decision making frameworks for software projects that build on our #NoEstimates work. You can sign up here. But before you do, email me and get a special discount code. If you manage software organizations and projects, there will be other interesting workshops for you in the same days. For example, the #MobProgramming workshop where Woody Zuill shows you how he has been able to help his teams significantly improve their well-being and performance. #MobProgramming may well be a breakthrough in Agile management. Picture credit: John Hammink, follow him on twitter Categories: Blogs ### A Creativity (R)Evolution TV Agile - Mon, 08/18/2014 - 21:24 We are incessantly, almost compulsively drawn to gatherings of intelligent, creative people. While we are looking to learn ways to change our professional and personal lives for the better with Agile approaches, on a deeper level, we’re compelled because we crave profound change and the inspiration to instigate a revolution. There’s a movement brewing built […] Categories: Blogs ### Next Cape Town talk: Product Owners: Dealing with Capacity and Prioritisation Scrum User Group of South Africa - Mon, 08/18/2014 - 10:51 During this session we will look at the various things POs need to focus on, manage and eventually master. The majority of the session will be spent on 2 areas that in our experience, many PO’s struggle with, capacity and prioritisation. To explain capacity we will use an analogy and help you self discover what […] Categories: Communities ### 5 minutes on scaling: Hangout & Co Scrum 4 You - Mon, 08/18/2014 - 07:40 Natürlich nutzen wir mittlerweile neben den physischen Taskboards auch JIRA und Co. Doch jedes Mal, wenn ich diese Tools nutze, gehen mir ihre Unzulänglichkeiten auf den Geist. Sie lösen im skalierten Umfeld das eigentliche Problem nicht: Sie helfen nicht, die Kommunikation zwischen den Scrum-Teammitgliedern einer weltweit aufgestellten Organisation zu vereinfachen. Vielmehr sind sie zu Datenbanken, Reporting Tools, perfektionierten Bug Tracking Tools und Forecast Push Systemen degeneriert. Selbst bieten diese Wesen keinen Mehrwert – sie müssen sich der Lebenszeit von Entwicklern und Managern bedienen, um am Leben zu bleiben. Dabei wäre es so einfach, ein wirklich funktionierendes, agiles Scrum-Tool zu entwickeln. Eines nämlich, das Arbeit beschleunigt und Kommunikation erleichtert, statt zu einer Belastung zu werden. Dazu bräuchte es nur ein paar Entwickler, die nach folgendem Rezept das perfekte Scrum-Tool bauen: 1. Man nehme ein wirklich funktionierendes, d.h. stabiles Video Conferencing System wie zum Beispiel Google Hangout und verpasse ihm eine bessere Usability – sorry liebe Googles, das geht besser! 2. Man füge eine Prise Telefoneinwahl international und kostenfrei hinzu – für die Teammitglieder, die während des Daily Scrums unterwegs sind (sorry, noch ist WLAN oder LTE auf deutschen Autobahnen und im ICE zu instabil – vor allem bei Hochgeschwindigkeitsfahrten). 3. Dann mische man ein Whiteboard, eine Desksharing-Funktionalität, einen Persistent Chat und ein Taskboard hinzu. 4. Nun braucht man noch die Möglichkeit, Texte auffindbar zu erstellen, die u.a. aber nicht nur an den Stories hängen. Deshalb integrieren wir ein Wiki, das sich aber bitte so wie ein Google Docs verhält. 5. Für große Mengen an Bildern und Dokumenten brauchen wir noch Dropbox oder Evernote. 6. Als Dessert nehmen wir noch einen integrierten Kalender, ein Shared Adressbook und eine E-Mail-Funktionalität. Fertig. Alle zu Tisch, so kann man international arbeiten. Ach so: Die Reporting-Funktionalitäten fürs Management lassen wir weg. Fortschritte zeigen wir, indem wir fertige Produkte liefern – wir zeigen es nicht durch abgearbeitete Stories oder Tasks. Das ginge ja, wenn wir das Video-Chat-Programm so ausweiten könnten, dass wir ohne Probleme Demos auch für nicht Firmenmitglieder abhalten könnten. Naja, ich träume. Aber ganz ehrlich, wir brauchen solche Tools. Die Entwicklung in der postindustriellen Netzwerkgesellschaft geht hin zu mehr Remote-Arbeit (work were you are), denn Teams kaufen sich die Kollegen dort ein, wo sie eben wohnen. Einer meiner Bekannten wohnt in St. Pölten (Niederösterreich) und arbeitet täglich für ein kalifornisches Unternehmen als Entwickler – warum auch nicht. Softwareentwicklungs-Teams können das heute. Andere Firmen werden folgen. Wir müssen das möglich machen. Die Teams eines unserer Kunden arbeiten an zwei Orten in den USA, in China, in Indien und in München. Wir brauchen die Infrastruktur, um sie miteinander arbeiten zu lassen – und zwar produktiv. Und nein: Menschen zu einem Umzug oder hunderttausenden Flugmeilen mehr zu zwingen, ist keine wirkliche Alternative – weder steuertechnisch noch aus Sicht der Produktivität. Wissensarbeit braucht den Austausch, das miteinander Denken. Das geht in der Business Class des A380 nicht, da hilft auch die überfüllte Senatoren Lounge nichts mehr. Das ist nichts anderes als verlorene Lebenszeit. Verteiltes, skaliertes und mulitkulturelles, grenzüberschreitendes Arbeiten wird zum Alltag werden. Kleine, schlanke Firmen werden das mit einer Symbiose aus den günstigen Lösungen wie Google HO, Confluence, Evernote und Dropbox stemmen. Große, unbewegliche Konzerne werden folgen – und dafür teure Enterprise Tools einkaufen. Vor allem müssen wir es schaffen, auch den multikulturellen Aspekt zu berücksichtigen. Schweizer, Österreicher und Deutsche – wir sprechen eine Sprache und meinen etwas völlig anderes. Ein elektronisches Board, dessen Sichtbarkeit auf die Größe eines Monitors beschränkt ist, muss also etwas anderes können, als beim Verschieben der Tasks die Farbe zu wechseln. Related posts: Categories: Blogs ### Agile Executive Playbook Imagine that you are an executive of a company (and quite possibly some of you reading this are or have a direct line to an executive). You’ve heard about this thing called Agile and some of you have experienced it. However, Agile is still a bit confusing because in many cases, it appears to be occurring only at the development team level. Some of you believe that Agile is a set of practices and tools and may be surprised to know that it is nothing-more-and-nothing-less than a set of values and principles. Maybe some of you haven’t seen the connection between applying Agile and gaining the business benefits. What exactly is your role and responsibilities in moving your company toward Agile? Here is some guidance on what your responsibilities should be and what may increase your chances in deriving the business benefits of Agile. Strategic Shifts The key responsibility for the executive within the organizational scope is to become the sponsor of the Agile initiative. This highlights to the employees that Agile is important and increases the chances of buy-in. But simply proclaiming “make it so” isn’t sufficient. The executive must continue to be a key player in this on-going sponsor role. Here are strategic shifts that are beneficial: • Study the Agile values and principles. Knowing this language helps you become more conversant in Agile and to the teams and organizational players that are involved. Studying the values and principles will also help you ascertain if you really believe in them (or not). • Move away from the iron triangle of schedule, cost or scope and move to a framework focused on value. Prioritizing ideas via cost of delay will provide a much better value-driven pipeline of ideas. These ideas can be decomposed into increments that can then be validated with fast feedback loops. • Measure and adapt the flow of your end-to-end concept to cash pipeline. There is a tendency to focus on just development, but it is often other parts of the pipeline where ideas wait much too long. Consider value stream mapping to better understand waiting states and no or low value steps. • Adapt the organization from a hierarchical organization to more of a self-organizing organization. When employees feel that they have more ownership and decision-making of their work, they will apply much more brainpower and bring passion to their work. Key Sponsor Activities Now let’s take a look at the more in-depth activities that you as an executive should consider playing and why. These are more tactical, but since becoming Agile doesn’t happen overnight, they help keep the engagement and interest along the way. • Treat your Agile initiative as a journey. Because this does take time, it would benefit you to build an adaptable roadmap. This may be best handled with a small local team of Agile champions who are committed to adopting Agile and an Agile consultant who has experience in this area. To get a good understanding of what an Agile roadmap may look like, consider reading the book Being Agile: Your Roadmap to Successful Adoption of Agile. • Build a learning culture. Consider establishing an education vision on how to best educate your organization. Infuse the education with experiments and experience. I suggest starting with the Value, Flow, and Quality materials that provide the reader with great insight into many of these new concepts and ideas, along with case studies and activities. • As an executive, examine your own behavior and align it with the Agile mindset of Agile values and principles with a focus of delivering customer value. Are you speaking the language of Agile and the strategic shift that you are looking to achieve? • Provide funding for the Agile initiative. Funding should include meeting education needs, bringing in talent (coaches) as needed, and providing tool support. This may occur incrementally or per the budget cycle. • Periodically provide public support for Agile. Establish an Agile communication plan, of which portions can be executed over time to keep employees aware of the progress and accomplishments of the deployment. This may also include providing 'air cover' to the Agile deployment team and the coaches and champions and mitigating the risks that could prevent a move to Agile. • Consider your staff. Ask yourself, “are they Agile minded and aligned with the cultural shift that is needed?” You may need to be involved with making adjustments to staff members who cannot make the switch away from command-and-control. This can be hard to do, but if they don't, then those around them will not take the change seriously. • Learn how to read agile metrics and measures of success. Gaining an understanding of the lagging to leading metric path, sprint burn-downs, release burn-ups, value capture, release frequency, Agile Mindset, Values, and Principles (MVP) Advisor, and other Agile-related metrics can help ensure the organization is moving in the right direction. • Adapt the employee compensation model toward agile behaviors being sought and away from rewarding command-and-control attributes. To change behavior, recognize the behavior you want to change, evaluate the reward system, and adapt it to the behavior that is needed for Agile. Without aligning the reward system to Agile, you will not get to behavior you want. • Attend the Sprint Reviews of your top products within your organizational scope. This will give you a genuine sense of progress and see actual working functionality of your products. The intent of this article is to provide highlights of what an executive can do to get the most business benefits from their Agile initiative. There can be other perspectives and further details. As an executive (or those who have supported executives), what have you found helpful in your Agile journey? Categories: Blogs ### Ruby: Create and share Google Drive Spreadsheet Mark Needham - Sun, 08/17/2014 - 23:42 Over the weekend I’ve been trying to write some code to help me create and share a Google Drive spreadsheet and for the first bit I started out with the Google Drive gem. This worked reasonably well but that gem doesn’t have an API for changing the permissions on a document so I ended up using the google-api-client gem for that bit. This tutorial provides a good quick start for getting up and running but it still has a manual step to copy/paste the ‘OAuth token’ which I wanted to get rid of. The first step is to create a project via the Google Developers Console. Once the project is created, click through to it and then click on ‘credentials’ on the left menu. Click on the “Create new Client ID” button to create the project credentials. You should see something like this on the right hand side of the screen: These are the credentials that we’ll use in our code. Since I now have two libraries I need to satisfy the OAuth credentials for both, preferably without getting the user to go through the process twice. After a bit of trial and error I realised that it was easier to get the google-api-client to handle authentication and just pass in the token to the google-drive code. I wrote the following code using Sinatra to handle the OAuth authorisation with Google: require 'sinatra' require 'json' require "google_drive" require 'google/api_client' CLIENT_ID = 'my client id' CLIENT_SECRET = 'my client secret' OAUTH_SCOPE = 'https://www.googleapis.com/auth/drive https://docs.google.com/feeds/ https://docs.googleusercontent.com/ https://spreadsheets.google.com/feeds/' REDIRECT_URI = 'http://localhost:9393/oauth2callback' helpers do def partial (template, locals = {}) haml(template, :layout => false, :locals => locals) end end enable :sessions get '/' do haml :index end configure do google_client = Google::APIClient.new google_client.authorization.client_id = CLIENT_ID google_client.authorization.client_secret = CLIENT_SECRET google_client.authorization.scope = OAUTH_SCOPE google_client.authorization.redirect_uri = REDIRECT_URI set :google_client, google_client set :google_client_driver, google_client.discovered_api('drive', 'v2') end post '/login/' do client = settings.google_client redirect client.authorization.authorization_uri end get '/oauth2callback' do authorization_code = params['code'] client = settings.google_client client.authorization.code = authorization_code client.authorization.fetch_access_token! oauth_token = client.authorization.access_token session[:oauth_token] = oauth_token redirect '/' end And this is the code for the index page: %html %head %title Google Docs Spreadsheet %body .container %h2 Create Google Docs Spreadsheet %div - unless session['oauth_token'] %form{:name => "spreadsheet", :id => "spreadsheet", :action => "/login/", :method => "post", :enctype => "text/plain"} %input{:type => "submit", :value => "Authorise Google Account", :class => "button"} - else %form{:name => "spreadsheet", :id => "spreadsheet", :action => "/spreadsheet/", :method => "post", :enctype => "text/plain"} %input{:type => "submit", :value => "Create Spreadsheet", :class => "button"} We initialise the Google API client inside the ‘configure’ block before each request gets handled and then from ‘/’ the user can click a button which does a POST request to ‘/login/’. ‘/login/’ redirects us to the OAuth authorisation URI where we select the Google account we want to use and login if necessary. We’ll then get redirected back to ‘/oauth2callback’ where we extract the authorisation code and then get an authorisation token. We’ll store that token in the session so that we can use it later on. Now we need to create the spreadsheet and share that document with someone else: post '/spreadsheet/' do client = settings.google_client if session[:oauth_token] client.authorization.access_token = session[:oauth_token] end google_drive_session = GoogleDrive.login_with_oauth(session[:oauth_token]) spreadsheet = google_drive_session.create_spreadsheet(title = "foobar") ws = spreadsheet.worksheets[0] ws[2, 1] = "foo" ws[2, 2] = "bar" ws.save() file_id = ws.worksheet_feed_url.split("/")[-4] drive = settings.google_client_driver new_permission = drive.permissions.insert.request_schema.new({ 'value' => "some_other_email@gmail.com", 'type' => "user", 'role' => "reader" }) result = client.execute( :api_method => drive.permissions.insert, :body_object => new_permission, :parameters => { 'fileId' => file_id }) if result.status == 200 p result.data else puts "An error occurred: #{result.data['error']['message']}" end "spreadsheet created and shared" end Here we create a spreadsheet with some arbitrary values using the google-drive gem before granting permission to a different email address than the one which owns it. I’ve given that other user read permission on the document. One other thing to keep in mind is which ‘scopes’ the OAuth authentication is for. If you authenticate for one URI and then try to do something against another one you’ll get a ‘Token invalid – AuthSub token has wrong scope‘ error. Categories: Blogs ### Little's Law in 3D Xebia Blog - Sun, 08/17/2014 - 17:21 The much used relation between average cycle time, average total work and input rate (or throughput) is known as Little's Law. It is often used to argue that it is a good thing to work on less items at the same time (as a team or as an individual) and thus lowering the average cycle time. In this blog I will discuss the less known generalisation of Little's Law giving an almost unlimited number of additional relation. The only limit is your imagination. I will show relations for the average 'Total Operational Cost in the system' and for the average 'Just-in-Timeness'. First I will describe some rather straightforward generalisations and in the third part some more complex variations on Little's Law. Little's Law Variations As I showed in the previous blogs (Applying Little's Law in Agile Games and Why Little's Law Works...Always) Little's Law in fact states that measuring the total area from left-to-right equals summing it from top-to-bottom. Once we realise this, it is easy to see some straightforward generalisations which are well-known. I'll mention them here briefly without ging into too much details. Subsystem Suppose a system that consists of 1 or more subsystems, e.g. in a kanban system consisting of 3 columns we can identify the subsystems corresponding to: 1. first column (e.g. 'New') in 'red', 2. second column (e.g. 'Doing') in 'yellow', 3. third column (e.g. 'Done') in 'green' See the figure on the right. By colouring the subsystems different from each other we see immediately that Little's Law applies to the system as a whole as well as to every subsystem ('red' and 'yellow' area). Note: for the average input rate consider only the rows that have the corresponding color, i.e. for the input rate of the column 'Doing' consider only the rows that have a yellow color; in this case the average input rate equals 8/3 items per round (entering the 'Doing' column). Likewise for the 'New' column. Work Item Type Until now I assumed only 1 type of work items. In practise teams deal with more than one different work item types. Examples include class of service lanes, user stories, and production incidents. Again, by colouring the various work item type differently we see that Little's Law applies to each individual work item type. In the example on the right, we have coloured user stories ('yellow') and production incidents ('red'). Again, Little's Law applies to both the red and yellow areas separately. Doing the math we se that for 'user stories' (yellow area): • Average number in the system (N) = (6+5+4)/3 = 5 user stories, • Average input rate ($\lambda$\lambda = 6/3 = 2 user stories per round, • Average waiting time (W) = (3+3+3+3+2+1)/6 = 15/6 = 5/2 rounds. As expected, the average number in the system equals the average input rate times the average waiting time. The same calculation can be made for the production incidents which I leave as an exercise to the reader. Expedite Items Finally, consider items that enter and spend time in an 'expedite' lane. In Kanban an expedite lane is used for items that need special priority. Usually the policy for handling such items are that (a) there can be at most 1 such item in the system at any time, (b) the team stop working on anything but on this item so that it is completed as fast as possible, (c) they have priority over anything else, and (d) they may violate any WiP limits. Colouring any work items blue that spend time in the expedite lane we can apply Little's Law to the expedite lane as well. An example of the colouring is shown in the figure on the right. I leave the calculation to the reader. 3D We can even further extend Little's Law. Until now I have considered only 'flat' areas. The extension is that we can give each cell a certain height. See the figure to the right. A variation on Little's Law follows once we realise that measuring the volume from left-to-right is the same as calculating it from top-to-bottom. Instead of measuring areas we measure volumes instead. The only catch here is that in order to write down Little's Law we need to give a sensible interpretation to the 'horizontal' sum of the numbers and a sensible interpretation to the 'vertical' sum of the numbers. In case of a height of '1' these are just 'Waiting Time' (W) and 'Number of items in the system' (N) respectively. A more detailed, precise, and mathematical formulation can be found in the paper by Little himself: see section 3.2 in [Lit11]. Some Applications of 3D-Little's Law Value As a warming-up exercise consider as the height the (business) value of an item. Call this value 'V'. Every work item will have its own specific value. $\overline{\mathrm{Value}} = \lambda \overline{V W}$ \overline{\mathrm{Value}} = \lambda \overline{V W} The interpretation of this relation is that the 'average (business) value of unfinished work in the system at any time' is equal to the average input rate multiplied by the 'average of the product of cycle time and value'. Teams may ant to minimise this while at the same time maximising the value output rate. Total Operational Cost As the next example let's take as the height for the cells a sequence of numbers 1, 2, 3, .... An example is shown in the figures below. What are the interpretations in this case? Suppose we have a work item that has an operational cost of 1 per day. Then the sequence 1, 2, 3, ... gives the total cost to date. At day 3, the total cost is 3 times 1 which is the third number in the sequence. The 'vertical' sum is just the 'Total Cost of unfinished work in the system. For the interpretation of the 'horizontal' sum we need to add the numbers. For a work item that is in the system for 'n' days, the total is $1+2+3+...+n$1+2+3+...+n which equals $1/2 n (n+1)$1/2 n (n+1). For 3 days this gives $1+2+3=1/2 * 3 * 4 = 6$1+2+3=1/2 * 3 * 4 = 6. Thus, the interpretation of the 'horizontal' sum is $1/2 W (W+1)$1/2 W (W+1) in which 'W' represents the waiting time of the item. Putting this together gives an additional Little's Law of the form: $\overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W(W + 1)}$ \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W(W + 1)} where 'C' is the operational cost rate of a work item and $\lambda$\lambda is the (average) input rate. If instead of rounds in a game, the 'Total Cost in the system' is measured at a time interval 'T' the formula slightly changes into $\overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W\left(W + T\right)}$ \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W\left(W + T\right)} Teams may want to minimise this which gives an interesting optimisation problem is different work item types have different associated operational cost rates. How should the capacity of the be divided over the work items? This is a topic for another blog. Just-in-Time For a slightly more odd relation consider items that have a deadline associated with them. Denote the date and time of the deadline by 'D'. As the height choose the number of time units before or after the deadline the item is completed. Further, call 'T' the time that the team has taken up to work on the item. Then the team finishes work on this item at time $T + W$ T + W , where 'W' represent the cycle time of the work item. In the picture on the left a work item is shown that is finished 2 days before the deadline. Notice that the height decreases as the deadline is approached. Since it is finished 2 time units before the deadline, the just-in-timeness is 2 at the completion time. The picture on the left shows a work item one time unit after the deadline and has an associated just-in-timeness of 1. $\overline{\mathrm{Just-in-Time}} = \frac{1}{2} \lambda \overline{|T+W-D|(|T+W-D| + 1)}$ \overline{\mathrm{Just-in-Time}} = \frac{1}{2} \lambda \overline{|T+W-D|(|T+W-D| + 1)} This example sounds like a very exotic one and not very useful. A team might want to look at what the best time is to start working on an item so as to minimise the above variable. Conclusion From our 'playing around' with the size of areas and volumes and realising that counting it in different ways (left-to-right and top-to-bottom) should give the same result I have been able to derive a new set of relations. In this blog I have rederived well-known variations on Little's Law regarding subsystems and work items types. In addition I have derived new relations for the 'Average Total Operational Cost', 'Average Value', and 'Average Just-in-Timeness'. Together with the familiar Little's Law these give rise to interesting optimisation problems and may lead to practical guidelines for teams to create even more value. I'm curious to hear about the variations that you can come up with! Let me know by posting them here. References [Lit11] John D.C. Little, "Little’s Law as Viewed on Its 50th Anniversary", 2011, Operations Research, Vol. 59 , No 3, pp. 536-549, https://www.informs.org/content/download/255808/2414681/file/little_paper.pdf Categories: Companies ### Ruby: Receive JSON in request body Mark Needham - Sun, 08/17/2014 - 14:21 I’ve been building a little Sinatra app to play around with the Google Drive API and one thing I struggled with was processing JSON posted in the request body. I came across a few posts which suggested that the request body would be available as params['data'] or request['data'] but after trying several ways of sending a POST request that doesn’t seem to be the case. I eventually came across this StackOverflow post which shows how to do it: require 'sinatra' require 'json' post '/somewhere/' do request.body.rewind request_payload = JSON.parse request.body.read p request_payload "win" end I can then POST to that endpoint and see the JSON printed back on the console: dummy.json {"i": "am json"}  curl -H "Content-Type: application/json" -XPOST http://localhost:9393/somewhere/ -d @dummy.json
{"i"=>"am json"}

Of course if I’d just RTFM I could have found this out much more quickly!

Categories: Blogs

Mark Needham - Sun, 08/17/2014 - 03:49

I’ve been using the Google Drive gem to try and interact with my Google Drive account and almost immediately ran into problems trying to login.

I started out with the following code:

require "rubygems"

session = GoogleDrive.login("me@mydomain.com", "mypassword")

I’ll move it to use OAuth when I put it into my application but for spiking this approach works. Unfortunately I got the following error when running the script:

/Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive/session.rb:93:in rescue in login': Authentication failed for me@mydomain.com: Response code 403 for post https://www.google.com/accounts/ClientLogin: Error=BadAuthentication (GoogleDrive::AuthenticationError)
Info=InvalidSecondFactor
from /Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive/session.rb:86:in login'
from /Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive.rb:18:in login'
from src/gdoc.rb:15:in <main>'

Since I have two factor authentication enabled on my account it turns out that I need to create an app password to login:

It will then pop up with a password that we can use to login (I have revoked this one!):


session = GoogleDrive.login("me@mydomain.com", "tuceuttkvxbvrblf")`