Skip to content

Feed aggregator

Top 10 Agile & DevOps Blog Posts of 2015

Agile Management Blog - VersionOne - Tue, 01/12/2016 - 15:30

thumbnailTime flies when you’re having fun, right? We rushed through 2015 and we saw some excellent posts. Together with our bloggers our goal is to create free insightful and actionable content to help you with your agile and DevOps journeys.

To help us get started with a great 2016, we thought it could be helpful to share 10 of the most popular blog posts for inspiration:

1. Three Leadership Musts for DevOps 
To enable success, there are three “musts” that leadership should have when launching a DevOps movement. These “musts” are based on the premise that DevOps requires disruptive leadership.

2. 10 Benefits of Agile You Definitely Don’t Want to Miss Out On
Are you sure you’re receiving the most benefits of agile possible? Read this article to learn what nearly 4,000 of your agile peers said were the benefits of agile that their organizations are receiving.

3. ScrumMaster: Servant Leader or Secretary?
In Certified ScrumMaster (CSM) courses, many Scrum myths are busted. One such myth is that the ScrumMaster is somehow an administrative assistant to a development team, to a product owner or to an organization.

4. Top 10 Tips for Measuring Agile Success
Choosing the right agile metric to measure agile success is really simple, right? I wish that were the case, but in reality choosing the correct agile metric can be a little tricky.

5. What Kind of Agile Are You?
As many as 94% of organizations are practicing some form of agile according to 9th annual State of Agile survey™, yet I have first-hand experience seeing countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach. So how can you tell if your organization is doing agile right?

6. Measuring What Counts: Introducing the Better, Faster, Cheaper, Happier Measurement Framework
The single biggest problem we see is organizations not understanding why they are changing the way they work – they don’t visualize the goal, set any targets, measure the improvements, nor demonstrate the benefits generated. In this article we will look at one way to establish a measurement dashboard to support your agile transformation.

7. The 7 Best DevOps Books
With the relative newness of DevOps, there are not yet a ton of DevOps books. That’s why we’ve assembled a list of the 7 best DevOps books based on four criteria: the number of ratings from Amazon, the average Amazon rating, number of ratings from GoodReads and the average GoodReads rating. Both Amazon and GoodReads use a scale of 1 to 5 stars with 5 stars being the best.

8. Why Agile Won’t Make You More Productive
According to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity. This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

9. How the Words You Use Affect Your Team
Words have a huge impact on team members affecting their work and ultimately your project, yet we often don’t put much thought into the words we use every day. Check out some of the positive and negative connotations of traditional and agile project management words.

10. 7 Tips We Learned About SAFe from Dean Leffingwell
Here are seven tips I learned from the recent AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.” In addition, there were more questions than we had time to answer during the live event. I’ve attached the Q&A here.

What were some of your most memorable agile and DevOps blog posts of 2015?

The post Top 10 Agile & DevOps Blog Posts of 2015 appeared first on The Agile Management Blog.

Categories: Companies

Agile India, Bangalore, India, March 14-21 2016

Scrum Expert - Tue, 01/12/2016 - 14:00
Agile India is an intense conference lasting four days where you can learn from expert Agile and Scrum practitioners. You will be also able to network and share your knowledge and experience with over 1500 international participants practicing or exploring Agile, Scrum and Lean. In the presentation and tutorials of the Agile India conference, you can find topics like “Agile Portfolio Management”, “Disciplined Agile In A Nutshell”, ...
Categories: Communities

AgilePath.me

Growing Agile - Tue, 01/12/2016 - 13:23
Hello and welcome to 2016! Karen and I are hard at work setting up AgilePath.me – be sure to go sign up and be notified when it is ready! This is part of our crazy goal of inspiring 1 million agile coaches across the world. We believe all ScrumMasters, managers, Product Owners, team members and everyone else […]
Categories: Companies

Profiling zsh shell scripts

Xebia Blog - Tue, 01/12/2016 - 10:27

With today's blazingly fast hardware, our capacity to "make things slow" continues to amaze me. For example, on my system, there is a noticeable delay between the moment a terminal window is opened, and the moment the command prompt actually shows up.

This post explores how we can quickly quantify the problem and and pinpoint the main causes of the delay.

Quantifying the problem

Let's first see where the problem might be. A likely candidate is of course my ~/.zshrc, so I added 2 log statements: one at the top, one at the bottom:

date "+%s.%N"

This indeed showed my ~/.zshrc took about 300ms, enough to cause a noticeable delay.

Quick insight: zprof

Selection_054The quickest way to get an idea of the culprit is the zprof module that comes with zsh. You simply add zmodload zsh/zprof to the top of your ~/.zshrc, and the zprof built-in command will show a gprof-like summary of the profiling data.

A notable difference between gprof and zprof is that where gprof measures CPU time, where zprof measures wall clock time.

This is fortunate: CPU time is the time a program was actually consuming CPU cycles, and excludes any time the program was for example waiting for I/O. It would be fairly useless to profile zsh in this way, because it probably spends most of its time waiting for invoked commands to return.

zprof provides a fairly rich output, including information about the call hierarchy between functions. Unfortunately, it measures performance per function, so if those are long you're still left wondering which line took so long.

Digging deeper: xtrace

An approach to profiling zsh scripts that will give per-line metrics is using xtrace. Using xtrace, each command that zsh executes is also printed to file descriptor 3 using a special prompt which can be customized with the PS4 environment variable to include things like the current timestamp.

We can collect these detailed statistics by adding to the top of our ~/.zshrc:

PS4=$'\\\011%D{%s%6.}\011%x\011%I\011%N\011%e\011'
exec 3>&2 2>/tmp/zshstart.$$.log
setopt xtrace prompt_subst

And to the bottom:

unsetopt xtrace
exec 2>&3 3>&-

There are 2 problems with this detailed trace:

  • This approach will provide confusing output when there is any parallelism going on: trace messages from different threads of execution will simply get interleaved
  • It is an overwhelming amount of data that is hard to digest

When you're dealing with parallelism, perhaps you can first use zprof and then only xtrace the function you know is a bottleneck.

When you're overwhelmed by the amount of data, read on...

Visualizing: kcachegrind

If we assume there's no parallelism going on, we can visualize our zsh script profile using kcachegrind. This tool is intended to visualize the call graphs produced by valgrind's callgrind tool, but since the file format used is fairly simple we can write a small tool to convert our xtrace output.

Selection_050

Selection_052Summary

zprof is the easiest and most reliable way to profile a zsh script.

Some custom glue combined several existing tools (zsh's xtrace and kcachegrind) to achieve in-depth insight.

Applying this to shell startup time is of course a rather silly exercise - though I'm quite happy with the result: I went from ~300ms to ~70ms (now mostly spent on autocomplete features, which are worth it).

The main lesson: combining tools that were not originally intended to be used together can produce powerful results.

References:
Categories: Companies

The Agile Gymnasium

Agile Tools - Tue, 01/12/2016 - 09:34

IMG_0271

I used to be a weightlifter. All through college, and for much of my adult life I have been in gyms exercising in one form or another. I’ve had some modest success. The experience of joining a gym goes along some standard lines. You’ve probably done it yourself. You show up and they take you around the facility and orient you to the equipment. They may even go so far as to give you some very basic training. You get an introduction to circuit training and then they slap you on the butt and tell you to “go be awesome!” You can record your exercise sessions on this little card over here…

That’s pretty much it.

As you might imagine, the success rate with that sort of system is fairly low. A lot of people never come back (although many continue to pay their monthly dues). Those who do come back typically have no idea what modern exercise programming looks like and simply go through the motions: they ride the stair master, do a few sit-ups, and maybe do some curls. That sort of exercise has some marginal utility – you get some small amount of aerobic benefit, but it’s a far cry from exercising a meaningful percentage of most people’s potential.

Most people stop there, but there are a few who have a more ambitious goal in mind. They may be trying to improve their tennis game with better conditioning. They may be looking to build massive pectoral muscles (like most teenage boys). They may be trying to maintain their conditioning in the off season of their sport, perhaps like cycling in the winter. In other words, the purpose of their exercise is to improve their performance in some sort of real world scenario.

I’d like to pause for a moment here. I was listening to a discussion with some folks who owned their own gym and they had an interesting model. It had three tiers to it:

  1. Gym Work: Work in the gym is not like the real world at all. It is where you go to prepare for the real world. The gym is a safe place to work to the point of failure (that’s important) and to learn.
  2. Expeditions: Expeditions are adventures in the real world that are guided by a coach. So it is real world experience, but with someone there to guide you and help if you fail.
  3. The Real World: This is where it all comes together. Ultimately, this is where the training in the Gym and the experience in the expeditions pays off in terms of improved performance.

As a model for the role of training for high performance, I thought this made a lot of sense. There was one more thing that they added to this: They were capturing data on the entire group’s performance and analyzing it in order to provide better training for individuals in the future!

So when you join the gym, you use a training program that is similar to what others in the gym are using. Your performance of that program is measured and metrics across the entire population training in the gym are measured. Then experimental changes are made to the training program and their benefit (or lack thereof) is measured across the group. Gradually their training program improves over time. But the training isn’t just tested in the gym. They also track the performance of their members when they go on expeditions. This measures the effectiveness of their training program in the real world.

OK, enough about this gym. What if we could use the same metaphor for the way we train our development teams? Training would be a weekly thing. Something where you go in for training on a periodic basis to firm up your skills. There might be repetitions (pair programming, mob programming, etc.) and there might be coaching (coaching circles, etc.) and there might be someone who is coordinating the training program and measuring the performance across the entire group of trainees.

There could be expeditions from time to time. Hackathons where people get to try out what they have learned in the gym out in the real world. You know: build a real project, maybe deliver something over a weekend. Test out your mastery of your skills in the real world – with a coach there if you need it.

Then there is game day – the real world. You take what you have learned and join a team. You get to flex your massive coding and collaboration muscles and help build something challenging – something amazing. What a great model for development! But I’m not done yet…

Let’s take this model, we’ll call it the “gymnasium model”, and apply it to something like Certified Scrum Master Training. Right now, there is two days of class time and exercises and then they slap the CSM on you and send the newly minted CSM out into the world. It’s a hauntingly similar scenario to the average person’s experience at the Gym: welcome to scrum, now “go be awesome!” Maybe you do a few sprints, do a few standups and off you go. That’s about as agile as most people get. Seriously. You get some marginal benefit, but that’s about it. It could be so much more.

But what if we did things differently? What if instead of signing up for a 2 day class, you were to join an Agile gym. Maybe twice each week you go into the gym to “work out”. A coach would give you a workout, perhaps something like this:

1. Dysfunctional Standup
2. 3 Reps in the coaching dojo
3. 2 Sets of mob programming
4. 2 reps of code katas
5. 1 cool down with a retrospective

That’s just a sample workout. The Agile Gym is a safe place to try out new skills and to push ourselves. The coach would be responsible for measuring the effectiveness of the workout and modifying it over time. Experimenting with new techniques and combinations of methods and evaluating the outcomes. Of course, this is just training in the gym. From time to time we are going to need to test our our competence in the real world. The coach would provide some guided expeditions (perhaps twice a month). For example:

1. Participating in a Hackathon
2. Participating in a Startup Weekend
3. Participating in a Maker Fair

These are events in the real world that are important places to evaluate the effectiveness of our training in the gym. If our coding skills have improved, then we should do well at these events and build confidence in our ability to use our newfound skills in the real world. Speaking of the real world, hopefully now we would see the agile behaviors that we have practiced being manifested in useful ways in the actual projects that we are running from day to day. Our collaboration skills should be tight, our planning impeccable, our retrospectives revealing. And if we find any weak areas, then it is back to the gym for more training.

In this model, the gym is always open. You actually practice your skills and see improvement. What an amazing way to learn about agile!

It’s not a bad model really. Actually, it’s a really darn good one. Who wants to start a gym?


Filed under: Agile, Coaching, Scrum Tagged: Coaching, Gym, practice, Scrum, Training
Categories: Blogs

Multiple copies of Getting Value out of Agile Retrospectives

Ben Linders - Mon, 01/11/2016 - 21:22

Valuable Agile Retrospecives Multiple CopiesDo you want multiple copies of our ebook Getting Value out of Agile Retrospectives? For every member of your team, the whole department or company? Or to use it at school or at your university for students to learn about doing valuable retrospectives. You can now get multiple copies by buying an ebook package on Leanpub.

More than 10.000 copies have been downloaded of our successful book. Teams all over the world are using it … Continue reading →

Categories: Blogs

How To Stay Motivated for 2016 with a Vision Board

J.D. Meier's Blog - Mon, 01/11/2016 - 18:15
"Big thinking precedes great achievement." -- Wilferd Peterson

The way to stay motivated for 2016 is to begin with your end in mind.

Keep in mind that your end in mind is dynamic, and it will change as you change, but it's still a great place to start.

A simple way to visualize your end in mind is to create a Vision Board.  Here is an example of my Vision Board for 2016:

Vision Board for 2016

Here is the process I used to create an empowering Vision Board:

How To Create an Empowering Vision Board

The main idea of a Vision Board is to capture your big ideas in terms of your hopes, dreams, future habits, and your ideal life.  It’s a collage of images that reflect what you want your ideal future state to be.

Prime Your Mind for 2016 with a  Vision Board

The power of a Vision Board is really to prime your mind for success.   When you know what you want, you activate your Reticular Activating System (RAS).  Your RAS helps you notice things around you that are relevant (such as when you get a new blue car, suddenly you notice how many people have a blue car.)  When you know what you want, you also get more resourceful.  But more importantly, when you know what you want, other people can help you because you are clear on what you want to achieve.

It’s really hard to help somebody get what they want when they don’t know what it is.

When you have clarity in what you want, you create focus.  When you focus, you prioritize.  When you prioritize, it helps you stay motivated, but your future picture helps you inspire yourself from the inside out.

I think we all tend to walk around with some little pictures of our future self, maybe as a fuzzy idea, or maybe little scenes from the future, or maybe more like a daydream.   But you can bring that future into focus by creating a simple collage of inspiring images that paint a picture of the future that you want to make happen.

Create a Vision “Page”

While I set out to create a Vision Board, I actually ended up creating what I’ll call a Vision Page.  I figured that a page on the Web would be available to me whenever or wherever I needed it.

After reviewing a few options, I ended up creating my Vision Board for 2016 using Pinterest.

It was simple and straightforward.  All I had to do was create a new board and then add Pins to my board that reflect my dreams, goals, habits, and aspirations.  It was actually a fun process trying to find the right image to capture the right idea.

Draw from People, Books, Quotes, and Affirmations

To create my Vision Page, I looked for inspiring people, as well as inspiring books, quotes, and affirmations.   On the people side, I thought of people that reflect some of the attributes I’d like to have more of.  For example, imagine if I could solve problems like Tony Robbins or be creative like da Vinci or think better like Edward de Bono.

For books, I thought about how some books encapsulate really important ideas.  For example, In Eat to Win, Dr. Furhman focuses on eating the nutritarian way.   In all of his research and in medical outcome studies, Dr. Furhman found that nutritional density and focusing on nutritional excellence is the key to vibrant and radiant health.  In How To Have a Beautiful Mind, Edward de Bono focuses on creating curiosity, insight, and making things interesting through the power of perspective and by asking better questions.

For quotes, I have several quote collections you can draw from in the Great Quotes Collection, including Confidence Quotes, Happiness Quotes, Inspirational Quotes, Motivational Quotes, Personal Development Quotes,  and Productivity Quotes.

For affirmations, I had to rethink my limiting beliefs about affirmations.  For me, affirmations were always foo-foo, and I hated the examples that I found.  In my experience, all the affirmations I saw long ago use words I would never say in a way that I would never say them.  They seemed inauthentic.  Worse, the people that I knew that used affirmations weren’t every effective.  It seemed like they were reading spells from a magic book and didn’t even really believe what they were saying. 

It was more like saying some magic word phrases and hoping they would suddenly become awesome.

But then I thought about affirmations differently.  I realized that they can be a great way to intentionally change your thoughts, especially if you have thought patterns that don’t work for you.  Affirmations, just like quotes, can be simple little mantra for the mind.   But the key is that you have to find affirmations that work for you, and you have to word them in a way that’s simple, sticky, and meaningful for you.

I share some sample affirmations in How To Create an Empowering Vision Board but here are a couple of examples.  I can replace, “This sucks” with "I see my challenges as opportunities to learn and grow."  I can remind myself “I let go of worries that drain my energy.”  My personal favorite is a remind of self-reliance: "If it’s meant to be, it’s up to me."

Choose and create affirmations that remind and inspire you as you answer the question “Who do you want to be and what experiences do you want to create?”

Build Your Vision Board with Skill

If you want to stay motivated for 2016, then create your own Vision Board or Vision Page.  You can get started in just a few minutes, and if you really embrace it, your Vision Board can serve you throughout the year.  It will act as a reminder of what you want, but it can also help you get clarity and insight into the attributes and characteristics that you want to develop as part of your personal growth.

Your motivation will be a direct reflection of your ability to find the most inspiring images that pull your forward.

Don’t over-engineer it.  Keep it simple and make it easy to update.   For me, I just quickly found pages I could “Pin” and then I added a one-liner reminder of the key idea.  For example, I found an image of a Navy Seals team working out, and I added the note “Fit like a Navy Seal.”

Also, remember that it’s your future, ideal life.  Don’t let limiting beliefs or small thinking get in your way.  Dream big and make it a collage of the people, quotes, habits, goals, and ideas that inspire you.

Lastly, remember that motivation follows action.  So take some action and your motivation will follow.  The best way to take action is to just start.  If you get going with your Vision Board, chances are you’ll surprise yourself with some fresh thinking and some big bold ideas, and these will carry you forward for 2016.

And, if not, remember the famous saying by Mary Anne Radmacher:

“Courage doesn’t always roar. Sometimes courage is the little voice at the end of the day that says I’ll try again tomorrow.”

Enjoy.

Categories: Blogs

Group Problem-Solving Techniques

Scrum Expert - Mon, 01/11/2016 - 17:55
Making decisions in groups like Scrum teams is our daily bread. Together we ponder over the right architecture, we select tools and set rules that we should follow as a software development team. In case of errors we discuss and decide how to get rid of them once and for all. We discuss, exchange point of views, bring arguments… or even yell at each other. This ...
Categories: Communities

Debugging SSH on Mac OS X

As a developer SSH is something I have to think about maybe once every few months when I’m setting up a connection for someone pairing in tmux for example. Cutting and pasting public keys can cost real time when a line feed gets inserted inadvertently or something gets clipped.

So assuming ssh isn’t working and you can’t connect it turns out there’s a pretty helpful debug mode on the client and the server. For the client you simply add the -v mode and get a pretty good idea about what’s going on:

ssh -v tmux@10.0.1.4 -i ~/.ssh/tmux_ssh

If that isn’t enough then you can just launch another ssh service on another port in debug mode.

sudo /usr/sbin/sshd -d -p 4444

Then you can just connect your client to the debugging server with a port specification:

ssh -v -p 4444 tmux@10.0.1.4 -i ~/.ssh/tmux_ssh

From that you should be able to get enough information to quickly debug the problem.

(My first experience with SSH was way back in 2000 when our 16 year old Unix sysadmin switched all the developers to SSH from raw telnet overnight because he could. All of us were on Windows or Classic Mac OS back then without any default SSH client software, and it cost us at least a day of pain to get everyone back to work.)

Categories: Blogs

Lean Startup for Software Developers

TV Agile - Mon, 01/11/2016 - 15:51
In 2010, I was a freelance software developer, working for an eCustoms software provider. I had always wanted to create my own company but the more I learned about what seemed to be necessary to create your own business (writing a business plan, gathering 3-year projections about your market, etc.), the more I doubted my […]
Categories: Blogs

Accidental Agility

Leading Agile - Mike Cottmeyer - Mon, 01/11/2016 - 13:00

Thought Exercise One

Let’s say for the moment that I am the CIO of a mid-sized company. I have a team of 100 or so people building software. Let’s also say that those 100 people are largely dedicated to 10-15 smaller products, there are few dependencies between those products, and we are currently using traditional project management to coordinate the flow of value across the organization.

Let’s also say for the moment that my traditional project management approach isn’t working so well and I seem to have as many Project Managers as I have developers. I hear about this new way of working called agile, send my Project mManagers to a CSM class, and when they come back, I reorganize my people to be dedicated to products.

I give each product a product owner, maybe let some of the project managers or team members play the ScrumMaster role, I start building backlogs, plan in releases and two week cycles, and do all the roles, artifacts, and ceremonies prescribed by Scrum. I’m wildly successful with this new approach and now I am a convert to Agile.

Thought Exercise Two

Let’s say I get bored in my old job because things are going so well, so I decide to get a CIO gig with a larger more established company in the area. As part of my department, I have 500 developers working on a large monolithic legacy COBOL system. I have one core product, several smaller products, and market offerings that are a mix of several different products.

Like in my first gig, my new team has been using traditional project management to build software and it isn’t working. Because I had so much success with agile in my last company, I want to try out agile in the new company. I break all 500 or so of my people up into small dedicated teams, I find Product Owners, and I turn my Project Managers into ScrumMasters.

We are meticulous about doing Scrum the right way. We’ve named people to the roles, we are doing all the ceremonies, we are doing all the artifacts. Even thought is seems we are doing everything right, we aren’t getting the same results we got last time. All the training, coaching, and executive support isn’t making any difference this time around. What changed.

So What Did Change?

It’s tempting to want to blame the people. It’s tempting to want to blame how well they followed the process. It might even be tempting to think that agile doesn’t work everywhere and just go back to the old waterfall way of working with renewed vigor. The reality is that agile worked in the first company by accident. It failed in the second company by accident too.

Why?

The processes associated with Scrum are designed to work when you have a small cross-functional teams that can operate independently from all the other small cross-functional teams in the organization. In the first scenario because you had products, with little or no dependencies between them, the environment was a natural fit for agile and it worked.

In the second scenario, you have a situation where the environment was not conducive to agile. You had a monolithic infrastructure, poor architecture, competing business goals, interdependent products, and the teams could not work with any degree of autonomy. Too much coordination was required and it was difficult to make an independent decision.

Accidental Agility

This is something I see sometimes when we are out talking to executives about agile. You see, most executives at this point are familiar with agile. Some like it and believe it works. Some have seen it fail and are not bought into it’s benefits. Some executives have had success in one company and have failed in others and aren’t sure why it didn’t work the second time.

I call this phenomenon accidental agility. Accidental agility is when the processes of Scrum are native to what you have in place and they work without everyone fully understanding exactly why. We learned Scrum and it was just awesome. The trick is understanding why Scrum works, and what conditions lead to it’s success.

If those conditions are in place, great. If they are not, you have to create them. Following a process outside the context it was designed to operate within is a recipe for disaster.

The post Accidental Agility appeared first on LeadingAgile.

Categories: Blogs

To estimate or not to estimate – Is that a question?

Agile Estimator - Mon, 01/11/2016 - 02:00

 

800px-Gower_Memorial_Hamlet_2

Photo by Immanual Giel (CC BY-SA 3.0)

400 years ago, Hamlet wrestled with he question “to be or not to be?” He was contemplating his own possible suicide. He was not the first to ponder this. Many have dealt with this question since then. It is a nuanced question. Should someone kill themselves after a particularly crappy product demo? (If so, I would not be writing this.) Is suicide reserved for the terminally ill? In any case, this is not a post about suicide. This post is about the question that keeps rearing its head in the agile community:  should agile development be estimated? If so, what should be estimated and how?

I began developing software in the late seventies. As a lead developer and project manager, I was often involved in estimating. I worked for what was called a time sharing company. In those days, human time was cheap and computer time was dear. There were no microcomputers. Small and some medium size companies could not afford their own computers. They went to time sharing companies and service bureaus to buy computer time. At these companies we would program the solutions they needed We sometimes charged for this programming and sometimes not. The money was in charging for the running of these systems month after month. The estimates were guesstimates. Sometimes I guessed, sometimes the salesman guessed and other times management did the guessing. In any case, it was what Fred Brooks would call “gutless estimating” in “The Mythical Man Month.” Of course, the estimates were poor. Nobody cared as long as the software went into production.

During the eighties, there was a change in the economics of software engineering. Programmer productivity become more important. Software development teams had to plan their work and work their plan. Estimating was part of this. This decade saw the development of many estimating tools like function points and COCOMO. By the end of the eighties I was working for CSC. My client was an insurance company that I was helping to develop their own waterfall life cycle methodology. As part of this I helped them develop an estimating methodology. As the nineties began, estimating and programmer productivity became my primary focus at CSC. During that time, no one ever suggested that estimating was not necessary. It was just considered to be part of proper planning.

In retrospect, it is possible that some of these estimates were unnecessary. CSC did some software development on a fixed price basis. It wold seem that these bids were always driven by an estimate. Sometimes, they were and sometimes they were not. We might get some competitive intelligence that told us that EDS was going to bid $12 million for the job. If we decided to attempt to undercut them by $2 million to get the work, function points and COCOMO might have little effect on the decision. Most project were done on a time and material (T&M) basis. On the government side, this same contract vehicle was called cost plus. Whatever the name, the reality of the situation was that a customer would continue to fund development as long as there was confidence that the team was going to produce the desired software in a time frame and at a cost the customer could live with. Some of these projects were successful, others waste millions of dollars before being abandoned.

In 2003, I decided to begin work on a doctorate in computing. I enrolled at Pace University. They had an executive program that led to a Doctor of Professional Studies (DPS) in computing. The faculty of this program had been teaching about and using agile development techniques for several years. They taught their software development courses using agile development methodologies. They broke their classes into teams so that they could learn  to use eXtreme Programming techniques and later SCRUM. I wanted to apply the estimating approaches that I had used the decade before to agile software development. The department chairman, Professor Fred Grossman, was enthusiastic about the idea. Professor Joseph Bergin, one of his senior faculty members, was not enthusiastic as all.

Joe’s feeling was that you cannot estimate the time and effort involved in a project early in the life cycle. There was no point in trying. Instead, he suggested that someone should be willing to fund a development project at $250,000. This would allow a team to be assembled and the first few iterations of software development to be performed. He believed that they should be estimating stories with story points. After these first iterations, they would have a delivery rate, or velocity, associated with implementing the stories. Then the rest of the project time and cost could easily be calculated by applying that velocity to the remaining story points in the story backlog. Of course, Joe was still estimating, it was just a delayed estimate.

I had two problems with Joe’s approach. My first was that no one would give him the original $250,000 without a proposal with an estimate attached. A decade later, I am not so sure. I have seen people invest in all kinds of things without a clear idea of the expected payback. Much of the venture capital that is raised seems to be built on a sketchy idea and the presence of some credible individuals in the company being financed. There are other examples. In the seventies and eighties, Red Adair was the man you called if you had an oil well fire. He did not give estimates, he simply billed for the work he did. Members of the medical and legal professions often commence work without any kind of fixed price in place. Embarking on an important software development project without an estimate does not seem as far-fetched to me any longer.

I also believed that the initial iterations of an agile software development project are not representative of later ones. In particular, the velocity of doing them is likely to change. There is usually a learning curve associated with the first iterations. People are just starting to work together as a team. They may be using technical tools and techniques that are new to them. I believed that this made the initial iterations too unstable for reliable estimating. I still believe this.

Meanwhile, I was working as a function point counter and estimator. This decade saw a transition from more traditionally planned projects (TPPs) to more agile development projects. The function point community was not happy about agile development for the most part. Agile development projects did not produce the type of detailed system specifications that we were used to when looking at TPPs.

Fairly detailed documentation is usually needed to do a function point count. The should be a conceptual data model with the attributes specified. The counter needs descriptions of the interfacing files along with fields they contain and a list of the entities from the conceptual data model that they interact with. They need screen and report layouts along with data entities that they interact with. With TPPs, they often did not get all of this and had to attempt to make due with other artifacts that were available. With agile development, this information was seldom documented anywhere except the source code being developed.

People using function points to do early life cycle estimating had the same problem. Early in the life cycle there are no data models or detailed layouts of files, screens or reports. Thus, the function points cannot be counted. They must be estimated. Several approaches to estimating function points have been in use. I developed the Early Lifecycle Functionality Estimating (ELFE) process. ELFE provides an estimate of an an application’s size, in function points, at a point in the software development life cycle before function points can be counted. ELFE is designed use initial user stories to drive this estimate. I also developed a collaborative technique called Elf Poker to develop the initial user stories if necessary. Thus, Elf Poker and ELFE could front end traditional estimating models like COCOMO II and CORADMO to provide estimates of the time and effort necessary to complete the project. In any case, I wrote this up for my doctoral thesis. Both Fred and Joe were on the thesis committee. There were no more questions regarding the value of estimating in general. However, maybe someone should be considering whether estimating agile development projects is always valuable. When it is not, time and money could be saved by skipping it.

Ron Jeffries is one of the authors of the eXtreme Programming methodology. He has taken a real interest in the No Estimate Movement. His interest alone would give the movement credibility. Jeffries claims other proponents. Arlo Belshee is best known for his work on promiscuous pairing. Joshua Kerievsky is the author of “Refactoring to Patterns.” Chet Hendrickson coauthored “eXtreme Programming Installed” with Jeffries. All of these seasoned agile practitioners advocated some version of No Estimates. For all, it seems to involve not estimating user stories. For some, it may be a more pervasive approach to not estimating. In any case, Jeffries singled out Woody Zull and Neil Killick as being the primary voices of the No Estimate Movement.

Woody Zull is known for his work on mob programming and considers himself a No Estimate Pioneer. He became interested in some work being done by Vasco Duarte. Duarte wrote a book called “No Estimates.” The first thing that comes to mind is why do you need a book to tell you not to do something. Why not just stop? If there is someone compulsively estimating jobs, fire them. The book starts by quoting the Standish Group’s Chaos report. In summary it states that human beings are not very good at software development in general.  However, we are geniuses at software development compared to our abilities as estimators of software development. Duarte takes about 40 pages to make this point. For people involved in estimating day in and day out, he is preaching to the choir. For people less familiar with estimating, even those involved in software development, it may be eye opening.

There are another 150 or so pages in Duarte’s book. Does this just tell you not to estimate many different ways? No, the answer lies in the book’s subtitle: “how to measure project progress without estimating.” We are all kids sitting in the backseat of the family car on the way to Disneyland. Are we there yet? When will we be there. The answer to the first question is no. The No Estimate kids have to wait until dad has driven a few hours before he can answer the second question. Likewise, the No Estimate agile groups must wait until they have collected their own project data before answering the inevitable question, “when will the release be done?” This is what is explained in the No Estimate book. I had a flashback to Joe Bergin’s comments from a dozen years ago.

Neil Killick is best known for his No Estimates work. His blog, neilkillick.com, shows that he is a No Estimate guy who understands that estimates are here to stay. But as estimators, we must understand that rumblings from the No Estimate community have been going on for a long time and their ideas are also here to stay. We have to identify those cases where no estimate is really needed and not do estimates for them. We have to identify what does not need to be estimated and who should not be involved in the estimating process at all.  For example, it may make sense to allow software developers to spend their time developing systems and find someone else or some other way to produce estimates that might be necessary. The objective must be to deliver what our customers need. Sometimes this will include a complete estimate with cost and schedule, sometimes just a rough completion date and other times simply an assurance that work is progressing satisfactorily. We need everyone’s ideas to see that agile processes deliver value every day.

 

 

Categories: Blogs

Chapter on Sustainable Pace added to Continuous Improvement eBook

Ben Linders - Fri, 01/08/2016 - 15:45

A chapter about Sustainable Pace has been added to my new book Continuous Improvement – Doing whatever helps to become better and thus more valuable:

Agile promotes that teams work in a sustainable pace to deliver value to their customers. When teams are working under too much pressure, technical debt will increase and velocity of teams will go down. Under such circumstances it will be almost impossible to do any improvement. A sustainable pace is an essential condition to enable team to improve continuously.

Cover_Continuous_Improvement Continue reading →

Categories: Blogs

Are People Really Afraid to Change?

Leading Agile - Mike Cottmeyer - Fri, 01/08/2016 - 13:00

Maybe.

Sometimes.

But here is my take.

I think most people are reasonable.

If there is a better way to do something, they’ll consider it.

Just because they resist, doesn’t mean they are afraid.

It might mean you haven’t made a compelling case.

It might mean that they have legitimate constraints that you haven’t taken into consideration.

It might mean that they don’t value the same things you value.

It might mean their priorities aren’t the same as your priorities.

It might mean you haven’t created enough safety.

Sometimes we show up with a shiny new hammer and want to think that everything is a nail.

We are past the early adopter phase.

We aren’t talking about small startups here.

We are talking about large organizations that have been building software for a long time.

There is technical debt.

There is legacy code.

There is a legacy organization.

We are talking about large scale organizational refactoring.

That can be scary.

How do we make it safe?

The post Are People Really Afraid to Change? appeared first on LeadingAgile.

Categories: Blogs

Scandinavian Agile, Finland, Helsinki, March 7-8 2016

Scrum Expert - Fri, 01/08/2016 - 12:00
The Scandinavian Agile Conference is a two-day event organized by Agile Finland and focused on Agile software development and Scrum project management. It takes place in Helsinki and discusses Agile organizations, state of the art in programming practices and Agile coaching. In the agenda of the Scandinavian Agile conference you could find topics like “Transforming the software development industry”, “Clarity before speed: Plan-Do-Check-Act (PDCA) applied in ...
Categories: Communities

Workshops on Retrospectives and Increasing Agile Value

Ben Linders - Fri, 01/08/2016 - 10:53

ben_QCon-China-2015-12016 has started, my wish for everybody is to make it a great year. So let’s focus on doing real improvement to make it happen!

Several workshops on agile retrospectives and increasing agile value have been planned in 2016.

Categories: Blogs

The Scrum Alliance Problem We’re Not Solving……Yet!

Applied Frameworks - Fri, 01/08/2016 - 06:46

As of today, the Scrum Alliance identifies 322,157 people as Certified ScrumMasters (CSM). You can find 66,813 people identified as Certified Scrum Product Owners (CSPO), and a number of people have both certifications. Although the anemic number of Product Owners relative to ScrumMasters raises some questions, the more serious problem is the drop-off in people reaching the next level. Only 3,943 people achieved the level of Certified Scrum Professional.

This is not a small problem. This is an order of magnitude problem! And we need to solve it.

We need more people with three or more years of Scrum experience and demonstrated initiative to continue learning.

We need more people who have learned how to be successful leveraging Scrum to increase organizational value. And we need them to continue their success and to help others achieve success.

We need more Scrum coaches - both enterprise coaches and people striving for the new team coach certification. We need organizational change experts or, at the very least, people who have been through at least one change experience and have learned what works.

And we need more trainers. The 191 trainers and 80 coaches aren’t getting any younger. At the current rate of growth of CSPs, we may have a shortage of certified trainers and coaches within five years.

So, if you agree that the Scrum Alliance does have an important problem to solve, you may be wondering the same thing as me…What’s going on with the hundreds of thousands of people who haven’t reached CSP yet?

Could the certification be too hard to achieve?

The answer is subjective. To apply, people must:

  • Be a current holder of an active CSM, CSPO or Certified Scrum Developer credential.
  • Have at least three years of Agile/Scrum work experience within the past 5 years implementing Scrum in any role.
  • Gather and submit 70 Scrum Education Units (SEUs) from the past three years.
  • Invest $100 to apply and $150 when approved.

And people get a head start - 16 SEUs from the CSM class, up to 24 from CSD, and/or up to 16 from CSPO - and those certifications could have been earned more than 3 years prior to submitting the application. All other SEUs need to be earned within 3 years of the application.

So, over 300,000 people meet the first requirement. Based on membership statistics, over 150,000 people meet the second requirement, assuming they continued to apply Scrum after their classes in 2012 or earlier.

Perhaps the SEUs present a challenge?

  • Up to 45 SEUs may be earned from Scrum events like gatherings, local user groups or other Scrum Alliance events - 1 hour of participation = 1 SEU.
  • People can earn an unlimited number of SEUs working with CSTs, REPs and coaches. People can apply their initial training for this category. 
  • The next category is up to 15 SEUs at events outside the Scrum Alliance - like Agile conferences or other training.
  • People can also volunteer to provide non-compensated Scrum services for up to 15 SEUs.
  • The next bucket of up to 15 SEUs is independent learning - reading a book, preparing a presentation, watched a training video, writing a blog post or article, almost anything could apply.
  • The last category of up to 15 SEUs is other collaborative learning.

My subjective assessment is that gathering 70 SEUs isn’t too hard. So many activities qualify for credit that getting involved and continuing to learn in multiple ways seems very possible for most people.

Could the certification lack value?

Objectively, the market perceives relatively low value. A quick (unscientific) Monster.com search yielded 57 jobs for CSP compared to 1,432 for CSM and over 1,000 more for Product Owner. Further, while the number of CSPs continues to grow, the rate is nowhere near CSM or CSPO growth, which leads me to believe potentially qualified members may not perceive a lot of value either.

Subjectively, the value far exceeds the effort. For at least the short term, the CSP designation distinguishes people within the Scrum Alliance as high achievers. In the long run, CSPs will advance to team and enterprise coaching certifications and/or Certified Scrum Trainer. Beyond the extrinsic value, completing the Scrum professional certification provides intrinsic value - achieving the next level of personal mastery. 

Could the membership lack awareness?

Based on the people I meet in my CSM and CSPO courses, I observe very low awareness about the Scrum Alliance certification path and I make time to discuss what people can do next. In the past year, we collected additional qualitative and quantitative data that also shows relatively low awareness in the community. The upside - people ask a lot of questions about what to do next once they learn about CSP and the more advanced credentials.

Now What?

The Scrum Alliance community, particularly the certified trainers and coaches, as well as current CSPs, needs to increase CSP awareness and encourage more people to apply for CSP. We also need to reach out to organizations, particularly human resources, managers and other people who plan hiring and write job descriptions to explain the different credentials and the value of CSP (and the coaching designations).

And we need to offer help to navigate the journey. While the CSP FastPass program exists to provide extensive in-person and online training, one-on-one mentoring, group discussions, SEU tracking and application assistance, we continue to assist CSP candidates outside the program. If every trainer and coach helped one person a month in 2016, we could triple the number of new CSPs compared to 2015 and nearly double the total number of CSPs globally.

Let’s Go!

Categories: Companies

Start With Just Two Things

Rally Agile Blog - Thu, 01/07/2016 - 23:00

When it comes to agile, what’s the least you can do? If you're serious about improving what you deliver but your efforts are frustrated by apathy—or even hostility—when presented with change, how much change should you present? Do you have to change everything?  

I’m not putting this out there to encourage laziness or offer an easy way out. “Agile light” shouldn’t be anyone's goal. But with unnerving predictability, I see great companies with awesome people and unbelievable opportunities in front of them fall dishearteningly (or even pathetically) short because they don’t do enough.

Beyond the team-level Scrum/XP and Kanban we all know and love, there are just two practices, that if embraced, deliver on the fundamental promise of using agile methods within larger environments. Scrum alone doesn’t work. The delivery team is such a small component of the overall value chain that while Scrum offers benefits, it really doesn’t shift the needle.

The Agile Enterprise

Let’s be clear about what we’re after here. An agile enterprise can pivot, apply its muscle to capitalise on opportunities in the market or dull the blade of market threats. Look at the new products or segments your company has launched and compare them with the products that defined that market. How much of that market, or mindshare, have you already lost?

Before you say, “Yeah, but our customers are loyal/our product has more features/they trust our brand,” think about this. In a world where what started as a site for buying books is now delivering groceries, a search engine company is now an ISP and making cars, and a music label is sending people to space—you have to proceed as if your brand means nothing. The value of your enterprise brand is decreasing, while the liabilities of maintaining an enterprise brand are increasing.

The Easiest, Well-trodden, Fatal Path

So, if your goal is to be an agile enterprise and you’re doing water-scrum-fall, stop it. Seriously, cut it out.

Water-scrum-fall is the easiest, least disruptive way of introducing agile into an enterprise. But it should only ever be considered a stepping stone. Move on as fast as you can, even if you’re still not yet great at team agile practices. There are no better motivators for improvement than seeing results and demonstrating value. I struggle to think of a more effective way of undermining success than water-scrum-fall.

Get to the Point. You Said Just Two Practices?

Scrum and Kanban aren’t enough: these practices are a given and a gazillion companies can do them well. Being good at team agile isn’t a competitive advantage.

For me, these are the missing components:

  • Organizing your work into features
  • Planning those features into a two- or three-month timebox

Simple. Easy.

Features are simply small functional deliverables—the units of value our customers are looking for. Features solve customers’ problems: Does this app integrate with Twitter? Is this transaction secure? Does this process send me notifications?

Decouple your features and make them as independent as you can. Get started by estimating how much effort it will take to deliver them and what kind of value you and your customers will get from them. The delivery teams decompose features into stories (this is the link with Scrum/XP/Kanban).

Planning these features into a timebox forces a discussion with stakeholders about which ones are most important. "We have a capacity of 300 points for the next three months. How should we spend it?” Just as you always complete stories in an iteration, you always complete features within the timebox.

Organizing work into features and planning those features into a timebox require very different interactions with stakeholders. Change is always scary, but once stakeholders have confidence in the activities around that change, they’ll realize they’re getting more control, more visibility, confidence to experiment and courage to kill bad investments. Once the product teams have these new tools, they’ll find ways to shorten their own cycles and speed the time it takes to sense and respond to market opportunities. The effect compounds.

I’ve stolen referenced both of these ideas from SAFe®. Working with countless customers, I’ve learned that the vast majority of enterprises need to overcome the next hurdle—quickly—so that their portfolios deliver an order-of-magnitude increase in value to their customers.

Is That It?

Of course not. It’s just the start.

The next step may be big room planning, or a more formal adoption of SAFe, or one of the other frameworks like Disciplined Agile Delivery (DaD), Large Scale Scrum (LeSS) or Spotify. The rapidly emerging agile portfolio management practice looks at how we structure around the flow of work and customer value, rather than the more traditional emphasis on utilisation and resource efficiency.

But for now, incorporate these two practices. It’s the least you can do to start achieving tangible results and to create opportunities—without turning everything upside down.

David Borgeest
Categories: Companies

Scaling Agile Across the Enterprise: An Interview with Kelley Blue Book

Agile Management Blog - VersionOne - Thu, 01/07/2016 - 15:30

At Agile 2015, we had the opportunity to interview Stacy Lin, senior director of product intelligence at Kelley Blue Book, to find out how their organization is using VersionOne to successfully scale agile project management.

In the video below, Stacy talks about Kelley Blue Book’s positive relationship with VersionOne. As their agile needs have grown, VersionOne has been with them every step of the way.

Highlights

  • Kelley Blue Book’s transition proved successful and now VersionOne is implemented across many Cox Automotive business units
  • VersionOne offers a single, common platform to manage and prioritize work
  • Kelley Blue Book benefited from flexibility to meet the needs of Scrum and Kanban teams
  • Cox Automotive now has the opportunity to build an agile community of knowledge within the organization

Challenges

Kelley Blue Book, the only vehicle valuation and information source trusted and relied upon by both consumers and the automotive industry, started implementing agile in 2005. Initially, the teams began with sticky  notes to manage their backlog, stories and tasks. However, as the organization scaled agile in 2007, they realized they needed an online solution that could help them efficiently manage complex projects. Particularly when it came to reporting on the velocity and other metrics, they needed an alternative to the manual effort of entering data into Excel and SharePoint.

Solution

After an extensive evaluation of several agile lifecycle management solutions, Kelley Blue Book selected VersionOne because of its usability. They had a pilot for eight weeks with two teams – one on-shore and one off-shore. The teams not only found the solution easy to use, but they also increased productivity.  As a result, the management team decided to roll VersionOne out to all of Kelley Blue Book.  Since then, VersionOne has scaled with Kelley Blue Book’s agile adoption and now has more than 250 users on the platform. The use of VersionOne has been so successful, that the solution been implemented in many of the business units throughout Cox Automotive, Kelley Blue Book’s parent company.

Benefits

According to Stacy, “Kelley Blue Book and VersionOne have been very good partners for more than eight years. As agile adoption in the software development industry has grown, VersionOne  has continued to add new functionality to support the needs of enterprises that are scaling Agile. VersionOne has been a great support in our Agile journey.”

Now Kelley Blue Book and the other Cox Automotive business units have a common platform and a consistent language to easily manage their Agile initiatives. For example, when it comes to managing its top-rated website (KBB.com), an extremely large and complex website, the product managers and Scrum teams have the platform to efficiently manage their work at all levels. In addition, the Portfolio Kanban Board in VersionOne provides one clear view of where all the epics and portfolio items are in flight, so the leadership can see progress at-a-glance and make sure that teams are aligned with business priorities.

While the organization’s agile transformation started with just Scrum teams, over time there were teams that preferred Kanban. The inherent flexibility with VersionOne allows teams to use different methodologies and still provide an integrated view of all  agile initiatives in one platform.

Now that VersionOne has been implemented across Cox Automotive, the organization can share and start to build a community of knowledge. For instance, at the annual Cox Automotive Agile Open, all of the business units get together to talk about their agile practices and learn from each other.

Please visit VersionOne’s YouTube page for more video interviews.

 

The post Scaling Agile Across the Enterprise: An Interview with Kelley Blue Book appeared first on The Agile Management Blog.

Categories: Companies

Knowledge Sharing


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