Skip to content

Blogs

R: ggplot – Plotting a single variable line chart (geom_line requires the following missing aesthetics: y)

Mark Needham - Sat, 09/13/2014 - 13:41

I’ve been learning how to do moving averages in R and having done that calculation I wanted to plot these variables on a line chart using ggplot.

The vector of rolling averages looked like this:

> rollmean(byWeek$n, 4)
  [1]  3.75  2.00  1.25  1.00  1.25  1.25  1.75  1.75  1.75  2.50  2.25  2.75  3.50  2.75  2.75
 [16]  2.25  1.50  1.50  2.00  2.00  2.00  2.00  1.25  1.50  2.25  2.50  3.00  3.25  2.75  4.00
 [31]  4.25  5.25  7.50  6.50  5.75  5.00  3.50  4.00  5.75  6.25  6.25  6.00  5.25  6.25  7.25
 [46]  7.75  7.00  4.75  2.75  1.75  2.00  4.00  5.25  5.50 11.50 11.50 12.75 14.50 12.50 11.75
 [61] 11.00  9.25  5.25  4.50  3.25  4.75  7.50  8.50  9.25 10.50  9.75 15.25 16.00 15.25 15.00
 [76] 10.00  8.50  6.50  4.25  3.00  4.25  4.75  7.50 11.25 11.00 11.50 10.00  6.75 11.25 12.50
 [91] 12.00 11.50  6.50  8.75  8.50  8.25  9.50  8.50  8.75  9.50  8.00  4.25  4.50  7.50  9.00
[106] 12.00 19.00 19.00 22.25 23.50 22.25 21.75 19.50 20.75 22.75 22.75 24.25 28.00 23.00 26.00
[121] 24.25 21.50 26.00 24.00 28.25 25.50 24.25 31.50 31.50 35.75 35.75 29.00 28.50 27.25 25.50
[136] 27.50 26.00 23.75

I initially tried to plot a line chart like this:

library(ggplot2)
library(zoo)
rollingMean = rollmean(byWeek$n, 4)
qplot(rollingMean) + geom_line()

which resulted in this error:

stat_bin: binwidth defaulted to range/30. Use 'binwidth = x' to adjust this.
Error: geom_line requires the following missing aesthetics: y

It turns out we need to provide an x and y value if we want to draw a line chart. In this case we’ll generate the ‘x’ value – we only care that the y values get plotted in order from left to right:

qplot(1:length(rollingMean), rollingMean, xlab ="Week Number") + geom_line()
2014 09 13 16 58 57

If we want to use the ‘ggplot’ function then we need to put everything into a data frame first and then plot it:

ggplot(data.frame(week = 1:length(rollingMean), rolling = rollingMean),
       aes(x = week, y = rolling)) +
  geom_line()

2014 09 13 17 11 13

Categories: Blogs

R: Calculating rolling or moving averages

Mark Needham - Sat, 09/13/2014 - 10:15

I’ve been playing around with some time series data in R and since there’s a bit of variation between consecutive points I wanted to smooth the data out by calculating the moving average.

I struggled to find an in built function to do this but came across Didier Ruedin’s blog post which described the following function to do the job:

mav <- function(x,n=5){filter(x,rep(1/n,n), sides=2)}

I tried plugging in some numbers to understand how it works:

> mav(c(4,5,4,6), 3)
Time Series:
Start = 1 
End = 4 
Frequency = 1 
[1]       NA 4.333333 5.000000       NA

Here I was trying to do a rolling average which took into account the last 3 numbers so I expected to get just two numbers back – 4.333333 and 5 – and if there were going to be NA values I thought they’d be at the beginning of the sequence.

In fact it turns out this is what the ‘sides’ parameter controls:

sides	
for convolution filters only. If sides = 1 the filter coefficients are for past values only; if sides = 2 they 
are centred around lag 0. In this case the length of the filter should be odd, but if it is even, more of the 
filter is forward in time than backward.

So in our ‘mav’ function the rolling average looks both sides of the current value rather than just at past values. We can tweak that to get the behaviour we want:

mav <- function(x,n=5){filter(x,rep(1/n,n), sides=1)}
> mav(c(4,5,4,6), 3)
Time Series:
Start = 1 
End = 4 
Frequency = 1 
[1]       NA       NA 4.333333 5.000000

The NA values are annoying for any plotting we want to do so let’s get rid of them:

> na.omit(mav(c(4,5,4,6), 3))
Time Series:
Start = 3 
End = 4 
Frequency = 1 
[1] 4.333333 5.000000

Having got to this point I noticed that Didier had referenced the zoo package in the comments and it has a built in function to take care of all this:

> library(zoo)
> rollmean(c(4,5,4,6), 3)
[1] 4.333333 5.000000

I also realised I can list all the functions in a package with the ‘ls’ function so I’ll be scanning zoo’s list of functions next time I need to do something time series related – there’ll probably already be a function for it!

> ls("package:zoo")
  [1] "as.Date"              "as.Date.numeric"      "as.Date.ts"          
  [4] "as.Date.yearmon"      "as.Date.yearqtr"      "as.yearmon"          
  [7] "as.yearmon.default"   "as.yearqtr"           "as.yearqtr.default"  
 [10] "as.zoo"               "as.zoo.default"       "as.zooreg"           
 [13] "as.zooreg.default"    "autoplot.zoo"         "cbind.zoo"           
 [16] "coredata"             "coredata.default"     "coredata<-"          
 [19] "facet_free"           "format.yearqtr"       "fortify.zoo"         
 [22] "frequency<-"          "ifelse.zoo"           "index"               
 [25] "index<-"              "index2char"           "is.regular"          
 [28] "is.zoo"               "make.par.list"        "MATCH"               
 [31] "MATCH.default"        "MATCH.times"          "median.zoo"          
 [34] "merge.zoo"            "na.aggregate"         "na.aggregate.default"
 [37] "na.approx"            "na.approx.default"    "na.fill"             
 [40] "na.fill.default"      "na.locf"              "na.locf.default"     
 [43] "na.spline"            "na.spline.default"    "na.StructTS"         
 [46] "na.trim"              "na.trim.default"      "na.trim.ts"          
 [49] "ORDER"                "ORDER.default"        "panel.lines.its"     
 [52] "panel.lines.tis"      "panel.lines.ts"       "panel.lines.zoo"     
 [55] "panel.plot.custom"    "panel.plot.default"   "panel.points.its"    
 [58] "panel.points.tis"     "panel.points.ts"      "panel.points.zoo"    
 [61] "panel.polygon.its"    "panel.polygon.tis"    "panel.polygon.ts"    
 [64] "panel.polygon.zoo"    "panel.rect.its"       "panel.rect.tis"      
 [67] "panel.rect.ts"        "panel.rect.zoo"       "panel.segments.its"  
 [70] "panel.segments.tis"   "panel.segments.ts"    "panel.segments.zoo"  
 [73] "panel.text.its"       "panel.text.tis"       "panel.text.ts"       
 [76] "panel.text.zoo"       "plot.zoo"             "quantile.zoo"        
 [79] "rbind.zoo"            "read.zoo"             "rev.zoo"             
 [82] "rollapply"            "rollapplyr"           "rollmax"             
 [85] "rollmax.default"      "rollmaxr"             "rollmean"            
 [88] "rollmean.default"     "rollmeanr"            "rollmedian"          
 [91] "rollmedian.default"   "rollmedianr"          "rollsum"             
 [94] "rollsum.default"      "rollsumr"             "scale_x_yearmon"     
 [97] "scale_x_yearqtr"      "scale_y_yearmon"      "scale_y_yearqtr"     
[100] "Sys.yearmon"          "Sys.yearqtr"          "time<-"              
[103] "write.zoo"            "xblocks"              "xblocks.default"     
[106] "xtfrm.zoo"            "yearmon"              "yearmon_trans"       
[109] "yearqtr"              "yearqtr_trans"        "zoo"                 
[112] "zooreg"
Categories: Blogs

Poaching vs. Collaboration

Agile Tools - Sat, 09/13/2014 - 08:13

adventure-evening-fun-2029-825x550

No one wants advice, only collaboration. – John Steinbeck

Imagine you are working as part of a team on a project. One day your manager approaches you and says, “There is this really high priority project that has come up and we need you and your expertise on it. We are going to move you onto that team for the duration of the project. Is that OK with you?”

How would you feel about that? I know how I would feel. I would feel jerked around. I would not feel in control or part of the decision making. I might even feel that the value of my membership to the team that I’m already on is being discounted. In short, it would suck.

How do you think your team would feel about it? Would they feel like they were able to participate in, let alone determine, the membership of their team? They wouldn’t feel in control of anything either. In fact, they might even feel victimized by the whole experience. They might be thinking, “Geez, we are screwed. How are we going to finish this project without Joe?” They might even wonder why you were the one who was chosen. That could lead to all sorts of fun misunderstandings.

So what would you do instead? After all, there is this project or team that needs help. It’s a top priority – a higher priority than anything else you are working on now. How can we manage this situation without destroying the integrity of the team?

Instead of moving individuals we could take the problem to the whole team. Perhaps a manager would come and sit down with the team and describe what they need. They could explain the trade offs and the specifics of what the other team needs help with. Then they might ask, “Could you guys help this other team out…as a team.”

This would have all sorts of advantages. If a team needs help and you send them just one guy, you’ve increased your team size by one person. If instead, an entire team pitches in to help, then you get the resources of 6 or 7 guys. Forget whatever multiplier effect you might get from a closely knit team – which solution is going to deliver results faster? That’s right, the team of 7. And there is more benefit besides productivity. By engaging the team in this fashion you are asking them to remain a team, and to help another team. Team’s helping teams – what a great idea!

You don’t hurt morale. You leave the decisions on how to manage the problem to the teams – so they feel like they own the problem. They are engaged, they are helping someone else. It really does have a lot going for it.

So what about that other project you were working on? You know, the one that you had to put down to help out with that other team? What about that project? Wasn’t it important too? Sure, but it wasn’t as high a priority, so it waits. This encourages the kind of organizational focus where everyone is attending to the most important issues first, rather than scattering their efforts across multiple lower priority issues in the name of higher utilization or productivity.

So if you are currently in the habit of pulling people off of teams in order to solve resourcing problems, I’m here to tell you that there is another way. If you are open minded enough to give it a try, you might just find that it may be a better way.


Filed under: Agile, Teams Tagged: Collaboration, control, micro management, poaching, resource management, Teams
Categories: Blogs

Looking Back at the Past Two Years

Agile For All - Bob Hartman - Fri, 09/12/2014 - 23:30

Eric Engelmann of GeonetricI want to start this post by thanking Eric Englemann (yes, that is him on the right!), the CEO of one of our awesome clients, Geonetric. Almost two years ago he took a huge risk and completely changed their corporate structure. But he didn’t stop there, he committed to letting the world know how they were doing along the way. He and others in his company have been extremely open about their results, including how they were doing one year after the big change and again last month.

Well, two years ago Agile For All underwent a big change as well. It went from a single-member LLC where I was the founder, owner, only member and everything else. In other words I was on my own. Two years ago I merged Agile For All with Richard Lawrence’s company, Humanizing Work. We had worked together for several years prior to the merger, but actually merging our companies was a huge, risky step for both of us. How are we doing today?

In looking back over the past two years I think there are 3 main places where we may have made some mistakes, and 5 main places where we have had huge success. Let’s start with the bad, because they aren’t all that bad!

What we would do differently if we could?
  1. Meet more regularly to challenge our ideas and thoughts. As we learned more and more about each other we realized we not only complemented each other in many ways, but we also have the ability to effectively challenge each other’s thinking. Richard is obviously extremely knowledgeable about agility and other topics. Prior to our merger I often had ideas and had to analyze them by myself. Richard is able to easily poke holes in my ideas, and just as importantly, he is able to expand upon my thinking. Often we end up far away from where we started, but it is an awesome place! We didn’t know each other well enough to do this early on, but I wish it had been possible.
  2. Better integrate our content. For better or worse, Richard and I have different styles of workshop facilitation. Because of this it has been, and still is, difficult to integrate our content. As a result we teach to the same basic learning objectives, but in different ways. Interestingly though, we both have integrated something from the other person in our workshops. We both try to use Training From the Back of the Room (thanks Sharon Bowman!) techniques in our courses, so it isn’t a big stretch at times.
  3. Hire Angie sooner! Having a Marketing and Events Manager has taken so much off of our plates that we are able to keep our sanity. Plus, as any of you who have been to one of our workshops knows, she is just flat out awesome at what she does. I can’t even remember the last time something slipped through the cracks and caused an issue. But there are multiple times when she absolutely saved our butts because something horrible happened. How amazing Angie is has become a joke among our partners and ourselves. Earlier this year a partner said “Wow, this thing is amazing. Of course it is, Angie did it. Good job Angie!” So now we all say the same thing a lot, “This is amazing. Of course it is. Good job Angie!” Maybe we need to have that turned into some sort of emoticon just to save time in email? <grin>
What are the big wins we’ve had?
  1. Hiring Angie. Did I mention we should have done that sooner??? Not having to worry about logistics for our workshops has been a big load off of both Richard and myself. Things are there when we arrive, the rooms are properly set up and everyone has been informed about what to do and expect. It is awesome. But that’s not all Angie does. She does everything from answering the company phone line to completely planning our annual conference (more on that later).
  2. Pair-selling. Having two of us involved in the sales process has helped us better meet the needs of our clients. Richard and I have different experiences which allow us to relate to clients in different ways. We complement each other well when on sales calls and as a result we are better able to service clients.
  3. Having a great life/work balance. We are actually able to prioritize LIFE over work. Running a business yourself is hard work. It takes a lot of time and sucks up every minute if you let it. By merging, we have cut the overhead of running our businesses in half (just one business now instead of two). This has freed up both of us to enjoy life to the fullest. Richard takes time with his family to do downhill mountain biking (yes, he and his family are crazy!), while I have taken time to travel and enjoy golf in Hawaii and Scotland as well as other wonderful places.
  4. Working together at some awesome clients. While we can’t publish our client list, let’s just say there are others that are as much fun as Geonetric. OK, maybe not that much fun, but lots of fun for sure. Prior to our merger we worked together, but we still were competitors so we didn’t work at clients together, mostly we just referred business to each other. Now we actually get to work together at some of our clients and it is always an amazing experience.
  5. The Humanizing Work conference. This is clearly the biggest win we’ve had. When we merged our two companies we discussed what to do with the Humanizing Work name and website. We had a vague idea that we would keep it because it sounded like something we would use in the future. After all, our goal in our workshops is to help people understand how to create software in a way that recognizes the value of people. Last year we decided to host  conference specifically for people who had been to our workshops. While we call it a conference, our goal was to eliminate all the things we disliked about typical conferences. We had an awesome time and so did our conference attendees. If you have been to one of our workshops, you really need to attend this conference. You will never look at conferences the same way again!

In summary, I want to thank Eric for being an example of transparency, but more importantly, I want to thank Richard for being a great business partner and friend. The past two years have been awesome and I’m looking forward to seeing what happens in the future!

AngieOh, and this is Angie. If you see her at our conference or anywhere else, be sure to say “Hi, oh and good job, Angie!”

The post Looking Back at the Past Two Years appeared first on Agile For All.

Categories: Blogs

A Shorty Story on Launching an Agile Release Train

Agile Product Owner - Fri, 09/12/2014 - 19:24

In this short story, Alex Yakyma describes the launching of a (mostly) fictional Agile Release Train as part of an initial SAFe adoption and, most importantly, the courageous people that drive change and some of the interesting situations they face. You can download it here:

Pacific Express: A Short Story

It’s a fun, light read, and maybe points the way to new mechanisms for describing SAFe adoption “from the inside out.” The nice thing about this format is the ability to see and feel the people and cultural aspects of SAFe, because as a framework, it is just that, and it’s the people that do ALL the work.

Categories: Blogs

I crashed the web servers of a $100M+ multi-national corporation …

Derick Bailey - new ThoughtStream - Fri, 09/12/2014 - 14:00

error

2 Hours.

That’s how long it took me to fix the problem I caused, after crashing the production web servers for a $100M+ multi-national corporation.

And this wasn’t just a marketing site, mind you. This was *the* web presence, online catalog, parts information and primary means of contact for distributors and representatives for several of the largest and most well known brands in that company’s industry. And I crashed every last website the company had, for every brand, for 2 hours.

The Setup

It’s the year 2002. Microsoft had released their brand new .NET framework, Visual Studio and Visual Basic.NET systems. I dove in head first, setting aside my “classic” ASP (VBScript) and VB6/COM components. In a few short months, I had my first ASP.NET / VB.NET application ready to roll. It was the e-catalog for the company’s distributor and representative network. It replaced a manual upload and link process with a completely automated system that allowed product managers to log in and update the categories, products and PDF files on their own.

Less Than 30 minutes after deploying the application to the production servers, the entire suite of web sites that were hosted on those boxes were down and I was getting panicked calls from product managers and customer service reps. My boss was also getting calls from division and brand presidents / CEOs. It wasn’t a good day for me.

Those Pesky “return” Statements

I was panicked. Full on, heart attack, stomach dropping panic.

I turned to the internet to research the problem and help me solve my problem. Why were my database connections being eaten up? Why weren’t they closing, or recycling in the connection pool the way they were supposed to? I have my database connection “.close()” method right there, just like I always did in my classic ASP pages… right there, after my return statements, where I send the data back out to the page from the data access code.

Yeah, you can probably guess from that last line, that this is what my code looked like:

Return SomeData;
MyDatabaseConn.Close();

Oh, the horror when after nearly an hour and a half of searching, I found out that the “return” statement in VB.NET immediately exits the function where it is. How stupid is that? VB6 didn’t do it that way. VBScript (at the time) didn’t do it that way. Why would they change that in VB.NET?! I was horrified! But I was also under the gun to fix it, so I found every database connection “.close()” call and moved them one line above the return statement.

I deployed. It worked. The sites came back up and I slowly started to breathe.

And then my boss called me in to his office…

The Conversation

I sat down and looked at my boss, door closed behind us. I was ready to get fired.

He sat there and looked at me for a moment before asking if the sites were back up. Then he told me how many angry phone calls the customer service reps had received, how many bids we had lost because our reps and distributors couldn’t get the information they needed, and he gave an estimate of the money that we lost in the down time. it was more money than I would make in the next 2 months of work.

Then he asked me what I did wrong and what I learned from the problems and solutions. He wanted to know if I was going to make that mistake again and how I could avoid similar problems in the future.

Lastly – and quite shockingly to me – he told me how the CEO of the company was known to make mistakes of that caliber … every day… and that, while I had caused a lot of damage for a short period of time, it would be washed out by the end of the month.

Lesson Learned

The important lesson, he told me, was that I owned up to the mistake, dug in and fixed it, and learned how to avoid the problem in the future. I was, in his mind, a better developer at the end of that day. I had survived a catastrophic crash of my own making and I had fixed the problem, learning some very valuable lessons in business down time and in code that day.

Fail Your Way To Success

I’ll never forget that lesson. I was 23 years old, running the public web sites for multiple brands inside of a $100M+ manufacturing company. And my boss taught that that it’s ok to make mistakes – even big ones – as long as we can recover from them and learn from them

He taught me that we don’t need to be afraid of making mistakes. Rather, we need to be afraid of not learning from them.

 

– Derick

     Related Stories 
Categories: Blogs

Scrum Sense News 09/14 – Adventures in Europe

ScrumSense.com - Peter Hundermark - Fri, 09/12/2014 - 13:38

Welcome to our September newsletter and welcome to summer.

Franschhoek_text_LG_SCRT

 

This is the first Scrum Coaching Retreat in Africa. It is an opportunity for you to collaborate with other coaches, learning from each other and producing valuable outcomes that will have lasting benefit to our community and customers.

The theme of this retreat is “small improvements”, recognising that most big changes are better embarked on, digested and internalised one step at a time. Transforming the world of work is a big endeavour. We can contribute by meeting our customers where they are and helping them take one next step.

For first-time visitors to South Africa we promise you an awesome experience in the winelands surrounding our Mother City. Come early or linger an extra week to experience this special place in high summer. For local coaches we promise you deep interactions with some of the best Scrum coaches on the planet.

More information and registration. Twitter hashtag #scrcpt.

Joanne’s Adventures in Europe

CSM in Denmark with Bent MyllerupShortly after joining Scrum Sense in February this year I started my journey to become a Certified Scrum Trainer (CST). The process includes co-training with other CSTs around the world, so that I can get feedback to improve and, once I am good enough, I can get their recommendations that are essential to acceptance. For the past week I have been lucky enough to travel around Europe and co-train with some of the top CSTs and CSCs (Certified Scrum Coaches) in Europe. It has been a wonderful experience for me….more.

 

 

 

Kanban Training

ddab0739-d764-4739-b47d-b43c56234160The popular Applying Kanban (Foundation) course sold out in record time, and all seats have now been filled. We plan to run another course in May 2015, which we have already started taking bookings for. Reserve your place at the May 2015 Applying Kanban (Foundation) course Kanban foundational course provides insight and visibility to the “why” of doing things – Dean Harvey, Nedbank Ltd. We still have a few spaces available for our Improving & Scaling Kanban(Advanced) certified courses which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer, so be sure to secure your place!

 

 

Other News Lean Agile 2014 SA

Peter Hundermark will be presenting at LeanAgile SA 2014 (#LASA) in October.

Scrum Gathering South Africa  20-21 October

Scrum Sense will be at the Scrum Gathering in full force. Catch us presenting on the following subjects:

We hope to see you there. Last years gathering was awesome and packed with amazing speakers from all around the world.

The post Scrum Sense News 09/14 – Adventures in Europe appeared first on ScrumSense.

Categories: Blogs

Pair & Share - a simple technique for Sprint Planning

Scrum Breakfast - Fri, 09/12/2014 - 09:00
How do you get the team to plan tasks effectively?The second half of sprint planning is often a challenge for teams starting Scrum. It used to be their Project Leader would do the planning for them. Now the team has to figure it out for themselves! (Doesn't the Scrum Master do that? No!) How can you as a Scrum Master encourage your team to plan the Sprint effectively?

Many teams have difficulties doing task planning before they have thought about the technical concept. To address this challenge, I have a strategy I call "Pair and Share".
PreparationGood preparation is half the battle. This means that coming out of Sprint Planning 1, you should have a selected product backlog ("forecast") that consists of reasonably small stories. Six to 10 items in the forecast is a sign that the stories were small enough (assuming it is a good forecast).

Your team has had the conversations with the Product Owner, the Stakeholders, other Subject Matter experts, etc, and the confirmation is reasonably clear, perhaps in the form of a how-to-demo workflow, or other criteria which can be readily turned into an (automated) acceptance test. If you are still discussing the confirmation during the task planning, you probably have a long meeting in front of you ;-) Having said that, there is a reason the Product Owner should be in the room!
Pair and ShareHere's how it works:

As a Scrum Master, I would take a moment to remind the team about the importance of working according to priority, getting things really done (as opposed to getting a lot of stuff sort of but not really done), and of minimizing work in progress, especially unfinished work at the end of the sprint. The goal for this meeting is not to create the definitive technical concept or task planning, but to create enough of each that the team can start working.

Then timebox Sprint Planning 2, the second half of the meeting, to one hour per week of sprint. So for two weeks, that gives you two hours. Divide that again in two halves, in this case 1 hour each for conceptual work and for task planning.

Have the team pair off. So if you have 6 people in the team, you have 3 pairs. Each pair takes two or three stories (what does this say about how big the stories are?). They have 1/2 hour to come up with their initial technical concept for implementing each story. So they timebox their discussion to 10 or 15 minutes per story.

After the first half hour is up, each pair explains how they want to implement each story to the rest of the team. Short Q&A. You are probably timeboxing the presentation to about 5 minutes per story. The rest of the team can ask questions, so this "share" part builds shared understanding and serves as an initial design review. The discussion may cause the team to rethink their solution, which will influence the task planning.

So now an hour has gone by, and you repeat the process, this time for task planning. Split into pairs (possibly different pairs than the first time), take the top stories, and do 1/2 hour of task planning.

During the final half hour, the team meets in front of the task board. One by one, each pair posts and explains their task planning to the rest of the team.

So now, pairs have thought relatively deeply both about the technical concept and the task planning. The whole team is consulted, and the team is well positioned to work forward as a team to start implementing.

BTW 1 - It may be that the team wants to think more about a particular item before committing to that particular concept. That's OK! Just make a task, "Finalize Design" or whatever.

BTW 2 - How did I come up with this? One of my first teams asked themselves this very question, and this is what they came up with! It worked beautifully! So if this doesn't feel right for your team, give them the goals for the meeting and ask them how they want to do it! Maybe you should even do that first!
Categories: Blogs

Test Driven Organizational Change

Agile Tools - Fri, 09/12/2014 - 08:34

change-20272_640

Let’s just say I was testing the bounds of society. I was just curious. -Jim Morrison (1943 – 1971)

I’ve been contemplating experimenting with some change, but I’m not really sure what is going to work and what won’t. In some ways that dilemma mirrors my coding style. Often when I embark on a project, I’m not entirely clear whether or not what I’m doing will work or not. I mean, I think it will work…but I’m really not absolutely positive. When I code…stuff happens.

I guess I could be accused of rushing into coding without taking care to fully think the problem through. But when I’m swept up in the moment, I want to run with the momentum I have. Call me impulsive. I admire others who have the self discipline to worry through the analysis before they get started, but that’s just not me.

That’s why Test Driven Development has been such a lifesaver for me. It forces me to think about what I’m trying to accomplish before I write the code. It gives my approach a little rudimentary discipline, rather than simply stampeding into the code. Moo.

The question is, can I use TDD to help with organizational change? What would that look like? In order to do TDD we have to start by asking ourselves what the expected outcome of this process or change is. In terms of team performance, that might mean a change among many different metrics (i.e. velocity, throughput, etc.). So first you set up the test: what would the desired outcome of the change be? More software? Happiness? Safety? Openness? Joy? Perhaps it is the absence of something?

Example Change: I want to bring more openness to new ideas to our work.

Next, what are the things that would indicate success? A change in the number of releases? A subjective rating of mood? Maybe a count of unsolicited ideas? Keeping a resistance index (a count of protests per session)? A count of positive/supportive statements. Basically we are looking for some kind of measure that might give us an indication that we are passing our test.

Example Test #1: I will count new ideas that come up in team meetings on a daily basis – If the count is greater than 10, then the test passes

 

Wacky thought: would it be possible to measure all behavior change in relation to changes in code? How would a subjective notion like enhanced social safety within the team be reflected in the code base? Whoa…I think I just bent something important in my head when I bumped into that last thought.

Of course, just like for code, you probably wouldn’t write just one test for any given change. Like code, change is complex, so we are going to be well advised to create multiple tests for any given single proposed effort.

Example Test #2: I will count the number of new ideas that get shot down daily – if the count is less than 3, then the test passes

Great, now we have some tests, what next? Well in TDD we run the tests first and verify that they all fail. Yes, Martha, all the tests are red. Good! Now, and only now are we ready to create change.

Example Test Run: Day one, test 1: result is 4 new ideas – test fails. test 2: the result is 4 – test fails. We are red.

So we put our change initiative into place. But wait – we must keep in mind rule #1 of test driven development: do only the very simplest thing to pass the test. What does that mean? Well if you want people to be happy, what’s the very simplest thing we could do? Would you go to HR and initiate some sort of peer reward system complete with executive buy-in and a roll out program with sensitivity training? Or…would you make a point each day of telling someone how much you genuinely appreciate working with them? Remember, rule #1: KEEP IT SIMPLE!

Example Change: Add a new rule to the team agreement – you can’t say “no” to a new idea.

Then we run the tests again. Where do we fail? Where do we pass? Now we might have some interesting information!

So, before I forget, there is one last thing we should do: refactor. Now we need to go back and take a look at those tests and see if we can improve them. We also look for ways to improve the changes we made. Maybe instead of telling people how much you appreciate them, you give them a hug instead.

Then just like in TDD, we go back to #1 and repeat.

Of course we can’t call this Test Driven Development because that name is already taken. Maybe we could call it Test Driven Change? TDC…Yeah, that could work. Let’s call it Test Driven Change – if I can get three people to do it, then we’ll call it a movement!

 


Filed under: Agile, Coaching Tagged: Agile, Behavior, change, change management, Coding, TDD, Test Driven Development, Testing
Categories: Blogs

The Agile Reader – Weekend Edition: 09/12/2014

Scrumology.com - Kane Mar - Fri, 09/12/2014 - 04:39

Edit: I’ve noticed a lot of the Kindle-spam that’s suddenly been appearing. I’ve updated my search rules and edited this post to remove the spam. You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

 

Categories: Blogs

Helping Your PMO Help You

Leading Answers - Mike Griffiths - Fri, 09/12/2014 - 03:38
Do any of these traditional PMO scenarios match your agile team experiences? Your traditional PMO is so laughably outdated that most agile projects ignoring them; other projects produce token deliverables to appease them, but these bear little resemblance to anything... Mike Griffiths
Categories: Blogs

Cost, Value & Investment: How Much Will This Project Cost? Part 2

Johanna Rothman - Thu, 09/11/2014 - 23:12

This post is continued from Cost, Value & Investment: How Much Will This Project Cost, Part 1

We’ve established that you need to know how much this project will cost. I’m assuming you have more than a small project.

If you have to estimate a project, please read the series starting at Estimating the Unknown: Dates or Budget, Part 1. Or, you could get Essays on Estimation. I’m in the midst of fixing it so it reads like a real book. I have more tips on estimation there.

For a program, each team does this for its own ranked backlog:

  • Take every item on the backlog and roadmap, and use whatever relative sizing approach you use now to estimate. You want to use relative sizing, because you need to estimate everything on the backlog.
  • Tip: If each item on the backlog/roadmap is about team-day or smaller, this is easy. The farther out you go, the more uncertainty you have and the more difficult the estimation is. That’s why this is a tip.
  • Walk through the entire backlog, estimating as you proceed. Don’t worry about how large the features are. Keep a count of the large features. Decide as a team if this feature is larger than two or three team-days. If it is, keep a count of those features. The larger the features, the more uncertainty you have in your estimate.
  • Add up your estimate of relative points. Add up the number of large features. Now, you have a relative estimate, which based on your previous velocity means something to you. You also have a number of large features, which will decrease the confidence in that estimate.
  • Do you have 50 features, of which only five are large? Maybe you have 75% confidence in your estimate. On the other hand, maybe all your features are large. I might only have 5-10% confidence in the estimate. Why? Because the team hasn’t completed any work yet and you have no idea how long your work will take.
Technical Program with Communities of Practice

Technical Program with Communities of Practice

As a software program team, get together, and assess the total estimate. Why the program team? Because the program team is the cross-functional team whose job is to get the software product to done. It’s not just the software teams—it’s everyone involved in the technical program team.

Note: the teams have to trust Sally, Joe, Henry and Tom to represent them to the software program team. If the teams do not, no one has confidence in any estimate at all. The estimate is a total SWAG.

The delegates to the program team know what their estimates mean individually. Now, they “add” them together, whatever that means. Do you realize why we will call this prediction? Do Sally, Joe, Henry, and Tom have feature teams, service teams, or component teams? Do they have to add time for the experiments as they transition to agile? Do they need to gain the trust of their management? Or, are they already experienced agile feature teams?

The more experienced the teams are at agile, the better the estimate is. The more the teams are feature teams, the better the estimate is. If you are new to agile, or have feature teams, or have a mixed program (agile and non-agile teams), you know that estimate is way off.

Is it time for the software program manager to say, “We have an initial order-of-magnitude prediction. But we haven’t tested this estimate with any work, so we don’t know how accurate our estimates are. Right now our confidence is about 5-10% (or whatever it is) in our estimate. We’ve spent a day or so estimating, because we can spend time delivering, rather than estimating. We need to do a week or two of work, deliver a working skeletong, and then we can tell you more about our prediction. We can better our prediction as we proceed. Remember, back in the waterfall days, we spent a month estimating and we were wrong. This way, you’ll get to see product as we work.”

You want to use the word “prediction” as much as possible, because people understand the word prediction. They hear weather predictions all the time. They know about weather predictions. But when they hear estimates of work, they think you are correct, even if you use confidence numbers, they think you are accurate. Use the word prediction.

Beware of These Program Estimation Traps

There are plenty of potential traps when you estimate programs. Here are some common problems:

  • The backlog is full of themes. You haven’t even gotten to epics, never mind stories. I don’t see how you can make a prediction. That’s like me saying, “I can go from Boston to China on an airplane. Yes, I can. It will take time.” I need more data: which time of year? Mid-week, weekend? Otherwise, I can only provide a ballpark, not a real estimate.
  • Worse, the backlog is full of tasks, so you don’t know the value of a story. “Fix the radio button” does not tell me the value of a story. Maybe we can eliminate the button instead of fix it.
  • The people estimating are not the ones who will do the work, so the estimate is full of estimation bias. Just because work looks easy or looks hard does not mean it is.
  • The estimate becomes a target. This never works, but managers do it all the time. “Sure, my team can do that work by the end of Q1.”
  • The people on your program multitask, so the estimate is wrong. Have you read the Cost of Delay due to Multitasking?
  • Managers think they can predict team size from the estimate. This is the problem of splitting work in the mistaken belief that more people make it easier to do more work. More people make the communications burden heavier.

Estimating a program is more difficult, because bigness makes everything harder. A better way to manage the issues of a program is to decide if it’s worth funding in the project portfolio. Then, work in an agile way. Be ready to change the order of work in the backlog, for teams and among teams.

As a program manager, you have two roles when people ask for estimates. You want to ask your sponsors these questions:

  • How much do you want to invest before we stop? Are you ready to watch the program grow as we build it?
  • What is the value of this project or program?

You want to ask the teams and product owners these questions:

  • Please produce walking skeletons (of features in the product) and build on it
  • Please produce small features, so we can see the product evolve every day

The more the sponsors see the product take shape, the less interested they will be in an overall estimate. They may ask for more specific estimates (when can you do this specific feature), which is much easier to answer.

Delivering working software builds trust. Trust obviates many needs for estimates. If your managers or customers have never had trust with a project or program team before, they will start asking for estimates. Your job is to deliver working software every day, so they stop asking.

Categories: Blogs

Intel Case Study: 8 Trains in 2 months

Agile Product Owner - Thu, 09/11/2014 - 21:34

At Agile Israel 2014 , SPC Yariv Weltsch-Cohen from Intel MDO presented  a case study which recaps their journey into lean-agile transformation using SAFe to launch their first Agile Release Trains.

Intel wanted to standardize the planning and execution process they used to deliver programs for testing and categorizing their chips on different platforms. Scrum was their mode of work for a few years, and SAFe gave them a way to scale up to a program level. They saw this as a natural next step in their lean-agile evolutionary ladder, and a way to accommodate big organizational change. Being Intel, they didn’t just dip their toe into the water. Within 2 months they successfully deployed 8 Agile Release Trains across different geographies. What’s not mentioned in the study, but is noteworthy, is that within another quarter the 8 ARTs became 12 ARTs (~1500 employees) supporting the entire Intel product line.

The 28-page briefing provides their basis for choosing SAFe, and some interesting Q1 release results and conclusions. A few highlights:

• 1st RP is A LOT of effort, afterwards gets much easier.

• Predictability on track for 80% goal

• RP using SAFe recipe helped highlight dependencies and risks (even showstoppers) far in advance of what they saw before.

• Business Owners should take full SAFe training

• Scrum of Scrums is a critical ceremony—based on number of dependencies and learning throughout the PI.

Many thanks to Intel’s Yariv Weltsch–Cohen for spearheading such an ambitious launch and for taking the time to capture their experience and share it with the rest of us.

You can download the study here.

Stay SAFe,
–Dean

Categories: Blogs

Ten at Ten Meetings

J.D. Meier's Blog - Thu, 09/11/2014 - 17:54

Ten at Ten are a very simple tool for helping teams stay focused, connected, and collaborate more effectively, the Agile way.

I’ve been leading distributed teams and v-teams for years.   I needed a simple way to keep everybody on the same page, expose issues, and help everybody on the team increase their awareness of results and progress, as well as unblock and breakthrough blocking issues.

Why Ten at Ten Meetings?

When people are remote, it’s easy to feel disconnected, and it’s easy to start to feel like different people are just a “black box” or “go dark.”

Ten at Ten Meetings have been my friend and have helped me help everybody on the team stay in sync and appreciate each other’s work, while finding better ways to team up on things, and drive to results, in a collaborative way.  I believe I started Ten at Ten Meetings back in 2003 (before that, I wasn’t as consistent … I think 2003 is where I realized a quick sync each day, keeps the “black box” away.)

Overview of Ten at Ten Meetings

I’ve written about Ten at Ten Meetings before in my posts on How To Lead High-Performance Distributed Teams, How I Use Agile Results, Interview on Timeboxing for HBR (Harvard Business Review), Agile Results Works for Teams and Leaders Too,  and 10 Free Leadership Tools for Work and Life, but I thought it would be helpful to summarize some of the key information at a glance.

Here is an overview of Ten at Ten Meetings:

This is one of my favorite tools for reducing email and administration overhead and getting everybody on the same page fast.  It's simply a stand-up meeting.  I tend to have them at 10:00, and I set a limit of 10 minutes.  This way people look forward to the meeting as a way to very quickly catch up with each other, and to stay on top of what's going on, and what's important.  The way it works is I go around the (virtual) room, and each person identifies what they got done yesterday, what they're getting done today, and any help they need.  It's a fast process, although it can take practice in the beginning.  When I first started, I had to get in the habit of hanging up on people if it went past 10 minutes.  People very quickly realized that the ten minute meeting was serious.  Also, as issues came up, if they weren't fast to solve on the fly and felt like a distraction, then we had to learn to take them offline.  Eventually, this helped build a case for a recurring team meeting where we could drill deeper into recurring issues or patterns, and focus on improving overall team effectiveness.

3 Steps for Ten at Ten Meetings

Here is more of a step-by-step approach:

  1. I schedule ten minutes for Monday through Thursday, at whatever time the team can agree to, but in the AM. (no meetings on Friday)
  2. During the meeting, we go around and ask three simple questions:  1)  What did you get done?  2) What are you getting done today? (focused on Three Wins), and 3) Where do you need help?
  3. We focus on the process (the 3 questions) and the timebox (10 minutes) so it’s a swift meeting with great results.   We put issues that need more drill-down or exploration into a “parking lot” for follow up.  We focus the meeting on status and clarity of the work, the progress, and the impediments.

You’d be surprised at how quickly people start to pay attention to what they’re working on and on what’s worth working on.  It also helps team members very quickly see each other’s impact and results.  It also helps people raise their bar, especially when they get to hear  and experience what good looks like from their peers.

Most importantly, it shines the light on little, incremental progress, and, if you didn’t already know, progress is the key to happiness in work and life.

You Might Also Like

10 Free Leadership Tools for Work and Life

How I Use Agile Results

How To Lead High-Performance Distributed Teams

Categories: Blogs

Killing the Buddha

Agile Tools - Thu, 09/11/2014 - 08:41

imagesIJ4EINVG

 

“If you meet the Buddha on the road, kill him!”

This is a popular saying derived from an old Zen koan. When it comes to working with Agile projects I find this saying very appropriate. People who do Agile transformations typically talk about finding the Way (the road) and often speak with almost religious fervor regarding Agile processes.

In fact, Agile is really just one short step away from organized religion. You have daily meetings, attend retrospectives where we examine our patterns of behavior deeply, we worship idols with bizarre names like “Kanban” and “Scrum” and fight (flame) wars over them. We anoint our priests as guardians of that process (yes, I’m talking about you, Scrum Masters), and agonize endlessly over whether we and others are following the right path.

Wow, maybe Agile actually is a religion. That’s pretty scary. I’ve got to go sit down now.

OK, I’m back. What were we talking about? Oh yeah, killing the Buddha. So, given my little digression above, it would be pretty easy to rewrite that old Zen saying like this:

“If you meet an Agile Guru while on your journey (to excellence, improvement, whatever), kill him!”

Now aside from sounding terribly violent, what the heck do I mean by that? It turns out, that having an Agile guru around is pretty limiting when it comes to learning and continuing to grow. Whenever we have a guru like that, what do we do? We defer to his expertise. We wait for him to provide the answer and we stall our own learning journey. Having an Agile guru around can freeze an organization’s development. You end up limited to whatever level the guru is at.

fish

Many organizations have these characters lurking in their midst. Heck, I was one once. I still have a business card with a title of “Though Leader” emblazoned on it around somewhere. I’m here to tell you it can happen to anybody. One day you are a perfectly decent, self-respecting developer and then WHAM! you become an Agile Coach, or a Thought Leader, or a Lean Sensei, or any number of other wacky guru code names.

You become, THAT guy.

And trust me, you don’t want to be that guy. You know the one, the Agile guy? The guy who simply must render an Agile judgment every time he opens his mouth. The guy who everyone defers to when it comes to do all things Agile. To paraphrase the old Life cereal commercial “Is it Agile? Hey, let’s get Mikey. He’ll judge anything!”

…oh brother, I think I just dated myself straight back to the stone age.

So what do you do when you have an Agile guru? You get rid of him! What if YOU are the Agile guru? Now that’s awkward. Well, your mission is to eliminate that perception. How do you do that?

  1. Keep your mouth shut
  2. Stop telling people what’s Agile (see #1). Use pantomime or something instead.
  3. Bring in, find, unearth or otherwise manufacture someone who has more expertise than you do. Understand that by doing this, you will run the very real risk of learning something. Sorry.
  4. Rinse and repeat until nobody mentions Agile in your presence. Ever.

So if you find yourself or someone you love has become an Agile guru, take heart! There is a cure! The best thing you can do to avoid stifling (and annoying) everyone in your organization trying to get work done is kill the Buddha.


Filed under: Agile, Lean, Process, Scrum Tagged: Buddha, Kanban, Lean, mastery, Scrum, Sensei, Thought Leader
Categories: Blogs

Das Eis brechen – mit Stift, Papier und Visual Scrum

Scrum 4 You - Thu, 09/11/2014 - 07:45

Die beliebte Small-Talk-Frage: „Und was machst Du so beruflich?“ wird für Scrum Coaches, ScrumMaster und Consultants nicht selten zur Bewährungsprobe. „Ich bin ScrumMaster“ erzeugt in unwissenden, weil wenig technischen Berufsgruppen oft nur ein Stirnrunzeln und nicht weniger häufig ein müdes Lächeln ob des ulkigen Fremdwortes – auch gerne begleitet von der Frage, welchen Gürtel man denn da schon habe.
Und dann fängt es im Kopf an zu rattern: Wo fange ich jetzt mit der Erklärung an, bei Adam und Eva? Beim Rugby? Bei Nonaka, Sutherland und Schwaber? Egal, wofür man sich entscheidet, so wirklich trivial wird es selten. Und das obwohl Scrum nichts anderes macht, als die für die Produktentwicklung intuitiv richtigen Dinge in einen Rahmen zu packen und interdisziplinäre Teams in kurzen Zyklen gemeinsam an einer Lösung arbeiten zu lassen.

Hier verhält es sich mit Scrum wie mit jedem anderen Thema auf diesem Erdball: Wenn man nur tief genug drinsteckt, lässt sich der Grad der Komplexität nach Belieben erhöhen und ehe man sichs versieht, hat man die Zuhörer in den Schlaf begeistert. Und nicht nur im privaten Rahmen sind die Erklärungskünste des agilen Prozesshüters gefragt. Es liegt in der Natur seines Berufs, an den Schnittstellen der Scrum-Teams für ein gemeinsames Verständnis sorgen zu müssen und den Prozess weiter ins Unternehmen zu tragen.
Und damit ist es ja längst nicht getan. An dieser Stelle soll die Debatte darüber, ob ein erfolgreicher ScrumMaster technisches Verständnis haben muss oder nicht, nicht angefeuert werden. Fakt ist aber, dass ein Team nicht nur zwischenmenschliche Probleme aus der Welt schaffen muss, um das gemeinsame Ziel zu erreichen.

Wohl demjenigen, der es versteht, Stift und Papier in den Grundfunktionen zu bedienen: schreiben und skizzieren. Es ist kein Zufall, dass sich Boris Gloger Consulting und die Kommunikationslotsen zusammengetan haben, um Scrum Consulting und Visual Facilitation zu einem gemeinsamen Training zu verschmelzen. Für die Teilnehmer bedeutet das: Sie erlernen die bikablo® Grundtechnik und können sie direkt auf ihren Arbeitsalltag im agilen Umfeld anwenden.

Ein Schelm, wer glaubt, hier gehe es lediglich darum, schöne Flipcharts zu malen – getreu dem alten Politiker Schlachtruf „Inhalte überwinden“. Nein, hier geht es darum, sich, seine Teamkollegen, Kunden oder Stakeholder schnell und effektiv zu einem gemeinsamen Verständnis für eine Situation oder der Lösung eines Problems näher zu bringen.

ScrumFlow_VisualScrum

Angenehmer Nebeneffekt: Wenn Sie das nächste Mal jemand fragt, was Sie eigentlich machen, malen Sie es einfach auf!

Tipp: Visualisieren wie ein Meister – mit den Tipps aus unserem Training “Visual Scrum” sind chaotische und inhaltsleere Flipcharts Schnee von gestern. Melden Sie sich hier gleich zum nächsten Termin am 13. & 14. Oktober 2014 in Köln an!

Related posts:

  1. Visual Scrum
  2. The five secrets of a successful Scrum training | May 22nd , Recife, Brazil
  3. Servant Leadership

Categories: Blogs

Adventures in Europe

ScrumSense.com - Peter Hundermark - Wed, 09/10/2014 - 22:41
IMG_5392

Denmark trainees

Shortly after joining Scrum Sense in February this year I started my journey to become a Certified Scrum Trainer (CST). The process includes co-training with other CSTs around the world, so that I can get feedback to improve and, once I am good enough, I can get their recommendations that are essential to acceptance. For the past week I have been lucky enough to travel around Europe and co-train with some of the top CSTs and CSCs (Certified Scrum Coaches) in Europe. It has been a wonderful experience for me.

My trip started in Copenhagen, where I spent a wonderful two days with Carsten Feilberg, a friend and an incredible tester. We spent time refining our workshop for Let’s Test Oz where we will be presenting on Communicating Complex Information in Sydney next Tuesday. We have been designing the workshop over mail and Skype for the past couple of months and being together once more re-enforced the Agile principle that face-to-face communication is the best kind. We have come up with a great design and I am really looking forward to our session.

IMG_5393

CSM Aarhus with Bent Myllerup

My next stop was Aarhus also in Denmark. There I met up with Bent Myllerup, a very experienced CST and CSC with agile42. I spent two days co-training a public Certified Scrum Master (CSM) class with Bent in Denmark. Lucky for me the course was delivered in English. We had eight participants and received wonderful feedback. I was able to train some of the modules and learned some new techniques from Bent. I love being in a fresh context, because I can always learn new things and see how different people understand and take in information. It’s also interesting to see the European adoption of Agile, the different industries that are beginning to understand the value of empirical process control and fast feedback loops, and  working with teams instead of individuals. Bent speaks about a truck factor which I thought was a novel way of illustrating the point of resilience. The track factor is the number of people in a team that, if they were hit by a truck or won the lotto and left, the project would have to stop. So if you have only one key team member that knows everything and that information is not shared in some way with the team then you have a truck factor of one. A higher truck factor is better than a lower one. What is the truck factor of your teams?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

From Denmark I went to Berlin. Berlin is an amazing and crazy city. I arrived early on Saturday morning. Half of the city hadn’t woken up yet and the other half hadn’t been to bed. I was lucky enough to get to explore and see some of the sights. Sunday evening I met up with Andrea Tomasini, another very experienced and talented trainer and coach from agile42. We ran through our course plan for another CSM class on Monday and Tuesday. I got the opportunity to see Andrea in action and to train some of the course modules. I really enjoyed the way that both trainers focused not only on Scrum, but also on how important it is to be Agile. Transformation is difficult and changing your mindset early on is important. It’s also interesting to see how many companies both in South Africa and internationally have similar problems. We had 20 participants from all different backgrounds from gaming to building of aeroplanes. Who said Agile is just for software?

CSM in Berlin with Andrea Tomasini

CSM in Berlin with Andrea Tomasini

It’s amazing to see how many different contexts are interested in the principles and values of Agile and Scrum, and how many people are really keen and eager to learn. The Training from the Back of The Room approach also helps to encourage people to learn on their own and creates an atmosphere of excitement and energy.

All in all it was an amazing experience. I had the opportunity to work with some great coaches and trainers and to learn new things that I can bring home. I love how supportive and encouraging our community is, both in South Africa and internationally. This is a long and tough journey and I feel that this trip has really helped to get me to the next level.

I am looking forward to co-training the next CSPO course in Johannesburg with Peter starting 30 September. Maybe I will see you there. If not I’ll be speaking at the Scrum Gathering in Cape Town in October, or maybe I will catch you at Let’s Test in Australia next week!

The post Adventures in Europe appeared first on ScrumSense.

Categories: Blogs

Cloud Changes the Game from Deployment to Adoption

J.D. Meier's Blog - Wed, 09/10/2014 - 17:22

Before the Cloud, there was a lot of focus on deployment, as if deployment was success. 

Once you shipped the project, it was time to move on to the next project.  And project success was measured in terms of “on time” and “on budget.”   If you could deploy things quickly, you were a super shipper.

Of course, what we learned was that if you simply throw things over the wall and hope they stick, it’s not very successful.

"If you build it" ... users don't always come.

It was easy to confuse shipping projects on time and on budget with business impact.  

But let's compound the problem. 

The Development Hump

The big hump of software development was the hump in the middle—A big development hump.  And that hump was followed by a big deployment hump (installing software, fixing issues, dealing with deployment hassles, etc.)

So not only were development cycles long, but deployment was tough, too.

Because development cycles were long, and deployment was so tough, it was easy to confuse effort for value.

Cloud Changes the Hump

Now, let's turn it around.

With the Cloud, deployment is simplified.  You can reach more users, and it's easier to scale.  And it's easier to be available 24x7.

Add Agile to the mix, and people ship smaller, more frequent releases.

So with smaller, more-frequent releases, and simpler deployment, some software teams have turned into shipping machines.

The Cloud shrinks the development and deployment humps.

So now the game is a lot more obvious.

Deployment doesn't mark the finish.  It starts the game.

The real game of software success is adoption.

The Adoption Hump is Where the Benefits Are

If you picture the old IT project hump, where there is a long development cycle in the middle, now it's shorter humps in the middle.

The big hump is now user adoption.

It’s not new.  It was always there.   But the adoption hump was hidden beyond the development and deployment humps, and simply written off as “Value Leakage.”

And if you made it over the first two humps, since most projects did not plan or design for adoption, or allocate any resources or time, adoption was mostly an afterthought.  

And so the value leaked.

But the adoption hump is where the business benefits are.   The ROI is sitting there, gathering dust, in our "pay-for-play" world.   The value is simply waiting to be released and unleashed. 

Software solutions are sitting idle waiting for somebody to realize the value.

Accelerate Value by Accelerating Adoption

All of the benefits to the business are locked up in that adoption hump.   All of the benefits around how users will work better, faster, or cheaper, or how you will change the customer interaction experience, or how back-office systems will be better, faster, cheaper ... they are all locked up in that adoption hump.

As I said before, the key to Value Realization is adoption.  

So if you want to realize more value, drive more user adoption. 

And if you want to accelerate value, then accelerate user adoption.

In Essence …

In a Cloud world, the original humps of design, development, and deployment shrink.   But it’s not just time and effort that shrink.  Costs shrink, too.   With online platforms to build on (Infrastructure as a Service, Platforms as a Service, and Software as a Service), you don’t have to start from scratch or roll your own.   And if you adopt a configure before customize mindset, you can further reduce your costs of design and development.

Architecture moves up the stack from basic building blocks to composition.

And adoption is where the action is.  

What was the afterthought in the last generation of solutions, is now front and center. 

In the new world, adoption is a planned spend, and it’s core to the success of the planned value delivery.

If you want to win the game, think “Adoption-First.”

You Might Also Like

Continuous Value Delivery the Agile Way

How Can Enterprise Architects Drive Business Value the Agile Way?

How To Use Personas and Scenarios to Drive Adoption and Realize Value

Categories: Blogs

Planning Feedback: Don’t Panic!

Agile Tools - Wed, 09/10/2014 - 08:31

Ring the Alarm

So the other day a VP asked our team for an estimate on a project. Now, putting aside whatever feelings you may have about the usefulness of estimates, we did a little planning, a little investigating, a little debating, and came up with an estimate for the project. I brought the estimate back to the VP and then the fireworks began. Apparently he had been thinking of a different number than we had given him. He wanted it done in half the time that we had forecast.

Whoops.

Now at this point in the story a lot of teams will panic and come back with one of two reactions:

  1. Fight – “We can’t do that! That’s not Agile” (or some variation on that tired theme)
  2. Cave – “We have no choice…”

But wait a second, there is a middle path. You can agree, but ask what can be compromised in terms of scope or other project constraints. You see, a new project is not just a learning process for you. Its also  learning process for the customer too. When  you get that first feedback, DON’T PANIC!

There is one important part of the planning process that I often see get lost: iteration. Doing a single round of planning and then presenting it to your customer as “Take it or leave it” isn’t what I’d call much of a dialog.

What we should be doing is some lightweight planning then review with the customer. “That’s horrible!” They cry, and then you say, “So what number were you thinking of?” And they return with something totally preposterous. OK, that’s cool. “Is there functionality we can drop to hit that date?”

No.

Of course not. So you go back, you scratch your head, cut out all the fluff you can find…and you still are way off the desired estimate. So then you take it back to them and say, “Hey look, I know this isn’t what you wanted, but here is the ABSOLUTE minimum we can get away with.” At which point, the customer looks at you with a tear in their eye and says these magic words, “What CAN you give me?”

Now you have a real negotiation! It may not always play out this way, but hopefully you get the point. You can’t freak out when they give you that first reaction. Stay cool – this is the first time they’ve had to test their fantasies against your capabilities. They need to learn too. So give your stakeholders a chance to work together with you on figuring out just what is possible. Negotiate. The more iterations you go through, the better your chances of coming to an agreement that everyone agrees is the best.


Filed under: Agile, Process Tagged: Agile, estimates, estimation, executives, Feedback, panic, Planning, stakeholders
Categories: Blogs