Skip to content


Need for dedicated testers in Agile environment

Agile World - Venkatesh Krishnamurthy - Wed, 02/11/2015 - 14:52

Here is a short article for Zephyr’s guest blog

image Scrum recommends 3 roles, the Product Owner, Scrum Master and the team.  There is no dedicated role as a tester (or QA) if you are following pure Scrum.

Agile also recommends that the team members are expected to be cross functional with T-shaped skills popularly known as “Generalized Specialists”.

However, the challenge I have seen in many projects is how “generalized” one could be while performing the role. Most of the projects are, so budget and time constrained that everyone is part of the rat race. They just want to get things done, and there is hardly any time for the team members to learn from each other and building generalized skills.

Building cross-functional and T-shaped skills is not easy. It needs a dedicated attention, time, effort and $ is involved from the organization to enable this. One cannot ask a developer to sit with a tester for a few days and learn testing. Personally I believe that testers mindset is something that comes with passion. In addition, mindsets of developers and testers are different.

There is one more reason behind having dedicated testers, and this is due to “IKEA effect”. The Harvard article concludes that,

“When people use their labor to construct a particular product, they value it more than if they didn't put any effort into its creation, even if it is done poorly.”

In the context of this article, when developers create the code, they value their creation more than the testers. The developer doesn’t like someone finding fault with their creation. This is one of the reasons why one gets to hear all sorts of excuses from the developers.

Read rest of the article here


Categories: Blogs

remember that time when …

Derick Bailey - new ThoughtStream - Wed, 02/11/2015 - 13:00

Remember that time when your team’s tech lead got mad at you for asking a “stupid” question? Or when that comment on the issue you opened in that open source project belittled you for not already knowing what was “obvious”? Then there was that time you had some code on GitHub and someone pointed and laughed…


Remember how that made you feel?

A Pull Request

A friend of mine told me about a website that he was browsing – a directory of things. He noticed that one of the apps he liked was not listed so he contacted the site owner and suggested adding it. The person replied, asking my friend to open a pull request on GitHub.

Having an interest in technology, but zero experience with Git or GitHub, my friend cautiously opened a GitHub account, figured out what a “fork” was, and eventually edited the right file. On sending the edited file back in an attempted pull request, though, something went wrong. It wasn’t obvious what he had done, but he knew something wasn’t right.

The owner of the site laughed at the failed pull request attempt and made a snide remark about it in the comments.

My friend closed the pull request (and his GitHub account, I think).

A Code Review

I asked each member of my team to produce one design idea for a feature – bonus points if you had unit tests to prove the idea worked. A week later, several of the team members had working code and unit tests.

I was impressed!

Until one of the team members showed some code that didn’t quite seem right… and a unit test that only proved the mock object he was using worked as a mock object. It didn’t actually run any real code – just called a fake method on a mock object.

Most of the team, myself included, laughed. He didn’t.

At the end of the project, we were doing one on one reviews to see how things went on a personal level. That team member told me how miserable he had been through most of the project – with the “unit test incident” being one of the key triggers.

A Compounding Design Problem

I spent 3+ days of billable time tracking down a problem – a major problem; one that was catastrophic to the success of the project, if not addressed… quickly.

I finally found the source of the problem – an open source library that I was using had what I considered a design flaw.

I was tired. I was frustrated. I was more than a little angry at how much time I had spent tracking down this issue only to find it was because of a “stupid” design decision in this library. It was all I could do not scream and rant and call out decisions as dumb, in the issue ticket I opened. Even with some restraint, I certainly didn’t present my problems well. I blamed the code and design of the library far more than I should have and clearly made myself look bad.

I’ve Been There

I’ve been the one in power – the project owner, the tech lead, the open source project creator. I’ve been frustrated by the comments on my projects, the ranting about why something does or does not work a certain way. I was the guy that laughed when my team member didn’t understand the issues with his unit test.

I’ve also been the one that had no clue what I was doing. I’ve submitted issues against projects when it was my code that was the problem. I’ve been pissed off at the project and the owner, wanting to scream and yell… and I have screamed and yelled.

I’ve laughed. I’ve pointed fingers. I’ve raged with anger.

It’s Not Easy

Calm down. Stop typing that gut-reaction response. Does that person really need to know what you’re thinking right now?

It’s not easy. It really isn’t – especially when you’re right there, in person, talking face to face. Being able to calm down, back away and stop yourself from doing something stupid can be difficult when you’re upset, frustrated, tired, etc. But with the internet, at least, we have more opportunity to calm down. The time between reaction and response can be nearly infinite when communication is asynchronous. Email, Twitter, GitHub issues, and even “instant” messaging; these things are not so “instant” after all.

I was angry with the project and design decisions on that issue that took 3 days of my time. I’m still upset about the time I put in to this – but that’s my problem, not the person that created this project. So, I stopped myself from writing the worst of what I was thinking. I did my best to have a civil conversation with the project lead. Yeah, I probably made an ass out of myself anyways. It’s hard not to when you’re upset. I tried… maybe eventually I’ll succeed… one of these days.

I still suck at this. I still rage. I still laugh and point fingers. But I try, at least… sometimes.

Remember That Time When …

The next time you want to fly off the handle at a comment or critique, or when you find that bug or see that ridiculous code, stop to think about the last time someone ridiculed you or got pissed off at you for asking a question.

How did it make you feel?

Yes, I’ve been “that guy” – I’ve been the jerk, and probably will be again. But I’ve also been that other guy – the one that took time to help, even when my initial response was to be pissed off and angry.

Guess which of these attitudes – hubris, anger and shaming vs patience, kindness and a helping hand – has been the most influential in my career, my relationships and in the communities I am part of?

– Derick

Categories: Blogs

R: Weather vs attendance at NoSQL meetups

Mark Needham - Wed, 02/11/2015 - 09:09

A few weeks ago I came across a tweet by Sean Taylor asking for a weather data set with a few years worth of recording and I was surprised to learn that R already has such a thing – the weatherData package.

Winner is: @UTVilla! library(weatherData) df <- getWeatherForYear("SFO", 2013) ggplot(df, aes(x=Date, y = Mean_TemperatureF)) + geom_line()

— Sean J. Taylor (@seanjtaylor) January 22, 2015

weatherData provides a thin veneer around the wunderground API and was exactly what I’d been looking for to compare meetup at London’s NoSQL against weather conditions that day.

The first step was to download the appropriate weather recordings and save them to a CSV file so I wouldn’t have to keep calling the API.

I thought I may as well download all the recordings available to me and wrote the following code to make that happen:

# London City Airport
getDetailedWeatherForYear = function(year) {
                    start_date= paste(sep="", year, "-01-01"),
                    end_date = paste(sep="", year, "-12-31"),
                    opt_detailed = FALSE,
                    opt_all_columns = TRUE)
df = rbind(getDetailedWeatherForYear(2011), 
      getWeatherForDate("LCY", start_date="2015-01-01",
                        end_date = "2015-01-25",
                        opt_detailed = FALSE,
                        opt_all_columns = TRUE))

I then saved that to a CSV file:

write.csv(df, 'weather/temp_data.csv', row.names = FALSE)

If we want to read that back in future we can do so with the following code:

weather = read.csv("weather/temp_data.csv")
weather$Date = as.POSIXct(weather$Date)
> weather %>% sample_n(10) %>% select(Date, Min_TemperatureC, Mean_TemperatureC, Max_TemperatureC)
           Date Min_TemperatureC Mean_TemperatureC Max_TemperatureC
1471 2015-01-10                5                 9               14
802  2013-03-12               -2                 1                4
1274 2014-06-27               14                18               22
848  2013-04-27                5                 8               10
832  2013-04-11                6                 8               10
717  2012-12-17                6                 7                9
1463 2015-01-02                6                 9               13
1090 2013-12-25                4                 6                7
560  2012-07-13               15                18               20
1230 2014-05-14                9                14               19

The next step was to bring the weather data together with the meetup attendance data that I already had.

For simplicity’s sake I’ve got those saved in a CSV file as we can just read those in as well:

timestampToDate <- function(x) as.POSIXct(x / 1000, origin="1970-01-01", tz = "GMT")
events = read.csv("events.csv")
events$eventTime = timestampToDate(events$eventTime)
> events %>% sample_n(10) %>% select(, rsvps, eventTime)
                                                  rsvps           eventTime
36                                   London Office Hours - Old Street    10 2012-01-18 17:00:00
137                                          Enterprise Search London    34 2011-05-23 18:15:00
256                           MarkLogic User Group London: Jim Fuller    40 2014-04-29 18:30:00
117                                  Neural Networks and Data Science   171 2013-03-28 18:30:00
210                                  London Office Hours - Old Street     3 2011-09-15 17:00:00
443                                                      July social!    12 2014-07-14 19:00:00
322                                                   Intro to Graphs    39 2014-09-03 18:30:00
203                                  Vendor focus: Amazon CloudSearch    24 2013-05-16 17:30:00
17  Neo4J Tales from the Trenches: A Recommendation Engine Case Study    12 2012-04-25 18:30:00
55                                                London Office Hours    10 2013-09-18 17:00:00

Now that we’ve got our two datasets ready we can plot a simple chart of the average attendance and temperature grouped by month:

byMonth = events %>% 
  mutate(month = factor(format(eventTime, "%B"), %>%
  group_by(month) %>%
  summarise(events = n(), 
            count = sum(rsvps)) %>%
  mutate(ave = count / events) %>%
averageTemperatureByMonth = weather %>% 
  mutate(month = factor(format(Date, "%B"), %>%
  group_by(month) %>% 
  summarise(aveTemperature = mean(Mean_TemperatureC))
g1 = ggplot(aes(x = month, y = aveTemperature, group=1), data = averageTemperatureByMonth) + 
  geom_line( ) + 
  ggtitle("Temperature by month")
g2 = ggplot(aes(x = month, y = count, group=1), data = byMonth) + 
  geom_bar(stat="identity", fill="dark blue") +
  ggtitle("Attendance by month")
grid.arrange(g1,g2, ncol = 1)

2015 02 09 20 32 50

We can see a rough inverse correlation between the temperature and attendance, particularly between April and August – as the temperature increases, total attendance decreases.

But what about if we compare at a finer level of granularity such as a specific date? We can do that by adding a ‘day’ column to our events data frame and merging it with the weather one:

byDay = events %>% 
  mutate(day = as.Date(as.POSIXct(eventTime))) %>%
  group_by(day) %>%
  summarise(events = n(), 
            count = sum(rsvps)) %>%
  mutate(ave = count / events) %>%
weather = weather %>% mutate(day = Date)
merged = merge(weather, byDay, by = "day")

Now we can plot the attendance vs the mean temperature for individual days:

ggplot(aes(x =count, y = Mean_TemperatureC,group = day), data = merged) + 
2015 02 10 07 21 24

Interestingly there now doesn’t seem to be any correlation between the temperature and attendance. We can confirm our suspicions by running a correlation:

> cor(merged$count, merged$Mean_TemperatureC)
[1] 0.008516294

Not even 1% correlation between the values! One way we could confirm that non correlation is to plot the average temperature against the average attendance rather than total attendance:

g1 = ggplot(aes(x = month, y = aveTemperature, group=1), data = averageTemperatureByMonth) + 
  geom_line( ) + 
  ggtitle("Temperature by month")
g2 = ggplot(aes(x = month, y = ave, group=1), data = byMonth) + 
  geom_bar(stat="identity", fill="dark blue") +
  ggtitle("Attendance by month")
grid.arrange(g1,g2, ncol = 1)

2015 02 11 06 48 05

Now we can see there’s not really that much of a correlation between temperature and month – in fact 9 of the months have a very similar average attendance. It’s only July, December and especially August where there’s a noticeable dip.

This could suggest there’s another variable other than temperature which is influencing attendance in these months. My hypothesis is that we’d see lower attendance in the weeks of school holidays – the main ones happen in July/August, December and March/April (which interestingly don’t show the dip!)

Another interesting thing to look into is whether the reason for the dip in attendance isn’t through lack of will from attendees but rather because there aren’t actually any events to go to. Let’s plot the number of events being hosted each month against the temperature:

g1 = ggplot(aes(x = month, y = aveTemperature, group=1), data = averageTemperatureByMonth) + 
  geom_line( ) + 
  ggtitle("Temperature by month")
g2 = ggplot(aes(x = month, y = events, group=1), data = byMonth) + 
  geom_bar(stat="identity", fill="dark blue") +
  ggtitle("Events by month")
grid.arrange(g1,g2, ncol = 1)

2015 02 11 06 57 16

Here we notice there’s a big dip in events in December – organisers are hosting less events and we know from our earlier plot that on average less people are attending those events. Lots of events are hosted in the Autumn, slightly fewer in the Spring and fewer in January, March and August in particular.

Again there’s no particular correlation between temperature and the number of events being hosted on a particular day:

ggplot(aes(x = events, y = Mean_TemperatureC,group = day), data = merged) + 

2015 02 11 07 05 48

There’s not any obvious correlation from looking at this plot although I find it difficult to interpret plots where we have the values all grouped around very few points (often factor variables) on one axis and spread out (continuous variable) on the other. Let’s confirm our suspicion by calculating the correlation between these two variables:

> cor(merged$events, merged$Mean_TemperatureC)
[1] 0.0251698

Back to the drawing board for my attendance prediction model then!

If you have any suggestions for doing this analysis more effectively or I’ve made any mistakes please let me know in the comments, I’m still learning how to investigate what data is actually telling us.

Categories: Blogs

Retrospective Technique: What Did You Learn?

Learn more about our Scrum and Agile training sessions on

Retrospectives are a key part of continuous improvement in Agile teams.  The retrospective techniques that a team uses should be adjusted to the needs of the team.  In a Scrum team, for example, the ScrumMaster will often decide on the techniques to use based on the current issues facing the team and then facilitate the retrospective for the team.  There are some great resources which give you collections of tried-and-true retrospective techniques including Esther Derby’s book “Agile Retrospectives” and the amazing online tool “Retr-o-mat“.  As an active consultant and trainer, I am always looking for new techniques to share with my clients.  Sometimes, I even create a new one (or at least new to me).  The “What Did You Learn” technique is new: I’ve been using it and testing it for a few years now to refine it.

What Did You Learn?

By itself, this is a powerful question.  As part of my work with OpenAgile, I’ve been helping teams and organization to focus on learning as an even broader category than continuous improvement.  The Learning Circle and the processes in OpenAgile help with focusing on learning.  The question “what did you learn?” is very open ended, and can certainly work as an extremely simple type of retrospective in OpenAgile or in Scrum or other Agile methods.  Often people like to have a little more structure and guidance so the “What Did You Learn?” retrospective technique provides four categories of learning for people to think about, share, and discuss within a team.


Setup for this retrospective is very simple: a flip chart or whiteboard divided into four sections or columns works fine, along with a piece of paper for each person in the retrospective, divided up the same way, and sufficient markers and pens for everyone.  Here is a downloadable PDF version of the handout for the “What Did You Learn” retrospective.

The facilitator will also participate at various points if they are a member of the team (e.g. a ScrumMaster).  It is easiest to do this with a group in-person, but can also be done reasonably well with video or teleconferencing.


The facilitator introduces the retrospective with a welcome and, if necessary, a recitation of the Retrospective Prime Directive.  Then, the process is described to the group.  Each of the categories of learning is also explained as follows:

  • Questions.  When you can formulate a question about something, it means that you have learned about a gap in your knowledge.  In other words, you have discovered something that you would like to learn.
  • Information / Data / Facts.  These are specific details that relate to some area of knowledge or skill.  This category of learning is the simplest and is often what people focus on when asked “what did you learn?”  Information tends to be dry and unemotional.
  • Insights / Concepts / “Aha!” Moments.  Often when we have a collection of facts or an experience, we see a pattern or make interesting connections between things.  This leads us to the great feeling of an insight.  Insights tend to be exciting or scary and have an emotional component.
  • Action Items.  These are decisions about what we would like to do in the future, but they could be extremely short-term or very long-term or anything in between.

There are three main stages in the retrospective as follows:

  1. Individual Reflection.  For 10 to 15 minutes, each individual works silently to write down the things that they have learned in the appropriate category on the handout.  Everyone should try to get at least a couple things into each of the four categories, but more is welcome.
  2. Sharing with the Group.  Systematically going around the group and getting people to read from what they have written.  This is another 10 to 15 minutes.  This stage should not get bogged down in discussion, but brief clarifying questions should be welcome.
  3. Identifying Important Learning.  The group now has open discussion to decide on a small number of things it considers the most important that it has learned.  This could be based on popularity, but impact, depth, or uniqueness might also be factors in considering importance.  These are the items that get written down on the flip-chart.  This is usually the longest part of the retrospective and can take up to 30 minutes.


This is an excellent retrospective for a team that is going through a significant transition such as starting a new project, a major change in business direction for a product, or as a wrap up technique for sharing lessons learned with other parts of an organization.  It is not a good technique for a brand new team that hasn’t worked together before as there will be little common ground for deciding on the importance of peoples’ various shared learning.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

How Futurespectives Help Teams to Reach Their Goals

Ben Linders - Tue, 02/10/2015 - 17:29
Many agile teams are doing retrospectives at the end of their iterations to reflect on their way of working and find things that can be improved. But what if teams are starting up and trying to figure out how to do their work? A futurespective exercise can help teams teams to find ways to reach their goals, agree upon their way of working and define a Definition of Done. Continue reading →
Categories: Blogs

You Need Processes and Tools

Leading Agile - Mike Cottmeyer - Tue, 02/10/2015 - 15:25

Even in an environment where you have a single, ideal, co-located cross-functional team, I believe you’re going to need processes and tools. The more complex and distributed your organization, the more processes and tools you’re going to need. Doesn’t sound very agile does it? Well, get over it. You’re going to need processes and tools to enable individuals and interactions. If you can’t sit in your chair and make direct eye contact with everyone on your team, you need more processes and tools. Hell, even if you can see everyone, you’ll still need processes and tools. What is Scrum? A process framework. What is a team board? A communications tool.


I’m not dismissing the Agile Manifesto. I do prefer individual and interactions over processes and tools. I’m just trying to establish some context. Most of us don’t work in that ideal agile world. Rather, we have to operate within a series of non-ideal organizational constraints. Most people are sold on the idea of Agile. The values and principles resonate with us. But my job (and LeadingAgile) is to understand the goals of an organization and help them reach them.  We start by laying the foundation for an agile enterprise by forming teams and installing a Lean/Kanban based governance model, but maintaining focus on longer term planning, risk management, and dependency management.

Current State

Before laying the foundation, I look at their current organizational structure, I look at their current governance (processes) and I look at their current metrics to see how good that structure and governance is working out for them.

Future State with Process and Tools

Whatever the future state looks like, I expect two things to help get us there.

1. We need to provide clarity by making process policies explicit.
2. We need to demonstrate incremental improvements by using tools.

Do you agree with me? Maybe you disagree with me. I’d love to read your feedback.

The post You Need Processes and Tools appeared first on LeadingAgile.

Categories: Blogs

“Solving Today’s Complex Projects with Agility” Presentation

Leading Answers - Mike Griffiths - Tue, 02/10/2015 - 04:32
Next week, on February 18th, I will be presenting on “Solving Today’s Complex Projects with Agility” at the Society for the Economic Promotion of Gran Canaria (SPEGC), co sponsored by ITProiectus. I have been working with ITProiectus for a while... Mike Griffiths
Categories: Blogs

Book Review: The Lean Enterprise - Mon, 02/09/2015 - 22:39

This weekend I finished reading a copy of The Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly.

Top level summary: If you want to learn about the truly agile organisation, this is the book that shows you what it looks like.

The Lean Enterprise

I have read many books about agile, lean and organisations that build software, but this is the first that really brings it all together. Other books tend to be either too theoretical (founded from either Drucker or Taiichi Ohno) or with a very practical toolkit in a very narrow domain.

This book is aimed at executives and managers or organisations – the people with the authority to change to change the system. We know from W. Edwards Deming:

A bad system will beat a good person every time.

Like a book that was actually test driven by real-life questions, it provides answers to questions executives and managers ask time and time again.

The book is packed with information and provides solutions to problems that organisations, doing agile software development, struggle with in other parts of their organisation. Better yet they offer many examples of companies who are doing it right, proving that it is not just theory and that it can be done in many ways. There are many great stories from many industries demonstrating how different approaches can be yet still exhibit the lean attitude and culture that is so essential to success. I am also glad how much the authors focus on the importance of culture (and what people can do about it) and not just a single focus on either theory or tools.

The authors have done their research well, with excellent, tangible examples of lean concepts, practices and tools linked to much more detailed reading in a referenced article, paper or book. I would almost buy this book only to give people the reading list in the back – it is really that good. I have read many of the books referenced, and I remember how they challenged and changed my thinking in a positive way. After this book, my own personal reading list is also much richer.

What makes this book especially stand out for me is the pragmatic nature of the book. Even though, to many readers, the contents may appear idealistic or too unrealistic, the authors have given many examples of companies doing it, refer to many case studies or experiences where they have seen the practices and principles at work and shown their own insights into the challenges or dangers that lie ahead. This last part speaks volumes to the authors sharing their experiences about the questions some organisations have not even asked yet and advice on how to solve it. One good example is the paradoxical nature of balancing exploration through prototyping (discovery) against the disciplined nature of continuous delivery (e.g. additional work of well refactored code, tests and scripted deployments).

When I got to the end of the book, I knew that I would need to re-read the book for a deeper understanding because it is so rich with concepts and tools – some I have not had the chance to try out.

A perfect match for the target audience it was written for and a book that will continue to be relevant for many years to come.

Categories: Blogs

Feedback & NVC. Focus. #deliver

Mike Vizdos - Implementing Scrum - Mon, 02/09/2015 - 21:12 -- Cartoon -- Feedback and Non Violent Communication [NVC] (July 30, 2007)

Starting tough conversations about Software Development.

For many years, that has been the main idea around this blog.

The main idea is [slowly?] changing to help people use concepts from Scrum to help you Focus and #deliver.

This is what your customers and end users really care about. Results.

I’ve learned this from a ton of feedback over the years!

Seven years ago, one of the topics I blogged about was the topic of, “Giving and Receiving” feedback, from a hypothetical persona I call “Stan” — and still use today — in my CSM Workshops.  The original posting can be found HERE (yes, it is still relevant!).

Being effective at giving AND receiving feedback is something that both helps you start some tough conversations about software development AND now also with the new aim of this blog — learning how to use Scrum to Focus and #deliver.

As an introvert (yes, me… it’s one of the reasons I can take the time and “write” you what I am feeling!) it’s really hard for me to do this in real life.


I’ve had a ton of practice, and I still suck at this.  Well.  Sometimes.

I at least recognize now when I am in the midst of sucking at it, and sometimes I can do something about it.

One of the other techniques around giving and receiving feedback I have been trying to practice is something called “Non-Violent Communication [NVC]“.

I recently had the opportunity to chat about this topic with Dave Prior and Peter Green.  The 24 minute podcast is HERE.

Good stuff.  You can also just take a peek HERE to learn more about the topic of NVC (direct from one of the key sources).

Feedback.  And more.

It’s something I need to step up to the plate and get better at both giving and receiving.

It’s something that you’ll start seeing more of around the topic of using Scrum to help you Focus and #deliver.

It’s something that you can start using immediately in your daily stand-ups, sprint reviews, and retrospectives.

Pick one.  Start today.

What about you?

Share what you are learning about this topic with me — and the rest of your world — out on Twitter (@mvizdos), Facebook, or Google+.

How may I help you?

Also, to learn more what happens “behind the scenes” of these postings, subscribe to my private e-mail list.  It’s always on topic with no spam (I promise!).

Categories: Blogs

Managing Technical Debt with SonarQube

TV Agile - Mon, 02/09/2015 - 19:31
This talk discusses technical debt, the code quality factors, the SonarQube’s core ideas and its main features that simplify the process of tracking and improving software quality. SonarQube is an open source quality platform that makes it radically easier to track, manage, enhance the overall quality of your code and pay your technical debt on […]
Categories: Blogs

Agile Culture –> Self-Managing People

Agilitrix - Michael Sahota - Mon, 02/09/2015 - 16:49

Four years ago, I argued that Agile is a Culture System focussed on Collaboration and Cultivation. We may build on and refine this understand to see that Agile points towards a higher level of organizational consciousness and the benefits that come with it. In particular, Agile is about valuing people and setting them free to deliver.

The Agile Manifesto & Principles

Let’s use the Laloux Culture Model as a lens for understanding the Agile Manifesto. If you haven’t read about this yet, it is fantastic – go read it now – otherwise this post will not make much sense.

When we colour code each of the manifesto statements to match various stages of consciousness we get:

Individuals and interactions over processes and tools (Green)
Working software over comprehensive documentation (Orange)
Customer collaboration over contract negotiation (Green)
Responding to change over following a plan (Teal)

We see that the Agile manifesto is a mix of ideas from different levels.

Agile Principles
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (Green)
  • Welcome changing requirements, even late in  development. Agile processes harness change for the customer’s competitive advantage. (Teal)
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (n/a)
  • Business people and developers must work together daily throughout the project. (Green)
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (Green)
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (n/a)
  • Working software is the primary measure of progress. (Orange)
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (Teal)
  • Continuous attention to technical excellence and good design enhances agility. (Teal)
  • Simplicity–the art of maximizing the amount of work not done–is essential. (n/a)
  • The best architectures, requirements, and designs emerge from self-organizing teams. (Teal)
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Teal)

Note: Some principles are not colour coded since I didn’t really see how they fit. If you have ideas, please post a comment.

Agile is Teal/Green

When we tally up the results, we get the following for Agile Culture:

  • 6 – Teal Stage – Self-management, Distributed power, and emergence. 
  • 5 – Green Stage – People: purpose, values and empowerment
  • 2 – Orange Stage – Achievement

In a diagram, it looks like this:

Agile Culture

The Agile Manifesto is pointing to a way of working that is at the Teal/Green stage. Elements of Scrum such as emergence and self-organizing teams are very closely connected with the Teal stage.

In summary, Agile Culture is about organizations operating at a higher level of consciousness with self-managing people.

Implications for Using Agile

For organizations at the orange stage (most large companies) Agile will be experienced as a disruptive force. As all the elements of culture need to shift together, Agile will by necessity be watered down or contained. This is what we typically see – Agile Adoption – with Enterprise Agile or Scaling Agile.

The main challenge for Agile Culture is that it is only a partial specification for operating at a Teal/Green stage. As can be see from Whole Agile, we need to consider other cultural and organizational elements for a holistic solution. We must look beyond Agile to allow Agile to succeed. This is the path of organizational transformation.

The post Agile Culture –> Self-Managing People appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Culture Change: Reinventing Organizations The following infographic adapted from Frederic Laloux’s Reinventing Organizations shows:...
  2. Laloux Culture Model Looking for a way to help evolve your organization’s culture? Frederic...
  3. People over Process – Win with People Success comes from Valuing People When we simplify the Agile...

YARPP powered by AdBistroPowered by

Categories: Blogs

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

Scrum 4 You - Mon, 02/09/2015 - 08:45

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.

IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.

Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.

Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Categories: Blogs

The Great Productivity Quotes Collection Revamped

J.D. Meier's Blog - Mon, 02/09/2015 - 00:32

A while back I put together a comprehensive collection of personal productivity quotes.   It’s a combination of the wisdom of the ages + modern sages.   It was time for a revamp.  Here it is:

The Great Productivity Quotes Collection

It's a serious collection of personal productivity quotes and includes lessons from the likes of Benjamin Franklin, Bruce Lee, Peter Drucker, Tony Robbins Voltaire, and more.

Productivity is Value Divided by Time

My favorite definition is a simple formula from Steve Pavlina:

Productivity = Value / Time

I like the formula because of it’s simplicity and because of the insight it provides.  If you want to increase your productivity, then you can increase the value or reduce the time it takes, or both.

One of the things I remind my colleagues in the halls of Microsoft is that value is the ultimate short-cut.  If you know what’s valued, you can eliminate or reduce all the waste in between.

Productivity Hot Spots

To organize the productivity quotes, I use a simple frame of productivity Hot Spots:

Action, Approach, Efficiency / Effectiveness, Energy Management, Failure, Focus, Goals, Improvement, Motivation and Mindset, Planning, Opportunity, Self-Awareness, and Time Management.

I find these buckets are useful for organizing principles, patterns, practices, and even quotes.   There are a lot of productivity quotes, so using this frame helps group the quotes into more manageable themes.

The Ultimate Formula for Personal Productivity

It sounds so simple when I say it now, but it took me a while to figure out the ultimate formula for personal productivity.   Here’s the formula:

Work on the right things, at the right time, the right way, with the right energy.

In other words, start with the right things.  Trim your tree of opportunity and focus on the right branches and leaves that will bear the most fruit.   Work on these things at the right time.  It’s easy to miss windows of opportunity and time changes what’s valued.   We also have better times in the day to work on things than others.   Work on things the right way.  This is really about using better techniques.  If have the wrong technique, then throwing hours and effort at something will just waste your time.  Lastly, work on things with the right energy.  Your energy is your force multiplier since you won’t get more time in the day.

A simple way to think of the way to optimize your productivity is to use your best energy for your best results.

I share a simple system and a comprehensive set of proven practices for personal productivity in my book, Getting Results the Agile Way. (It’s been a best seller in time management, and it helps you master productivity, time management, and work-life balance.)

Productivity Strategies

Believe it or not, quotes are not just neat and fun little sayings.   The right quotes are actually pithy ways to share strategies and insights.  They can completely change your game.

Here are a handful of some of the strategies that I’ve learned for improving productivity and many of these strategies are echoed in The Great Productivity Quotes Collection:

Less is more.

Focus on quality.

Quotas and quantity can help you achieve quality.  (If you learn from your process and apply it.)

Value is in the eye of the beholder and the stakeholder.

Find better techniques to multiply your results.

Enjoy the process.

Spend more time in your strengths, and less time in your weaknesses.

Pair up to amplify your talents and capabilities.

Focus on continuous improvement.

Manage your energy, not time.

Reduce the time you spend and you’ll innovate in your process.

Use timeboxing to invest time more intelligently. (Set limits and boundaries so you don’t over-spend in the wrong areas of your life.)

Work smarter, not harder.

Change your approach when it’s not working.

Test your results.

Productivity is Power

There are many ways to think about productivity.   I like to think of productivity as power.  I think of power as the ability to take action.   When you exercise your ability to take action and concentrate your effort and your focus, you can make amazing things happen in work and life.

Productivity is a powerful tool in your toolbox for personal empowerment.

As with anything, make sure you use the right tool for the job.  And that’s why I continue to fill my toolbox with several tools.  Otherwise, if all you have is a hammer, then everything looks like a nail.

You Might Also Like

The Great Personal Development Quotes Collection Revamped

The Great Leadership Quotes Collection Revamped

Happiness Quotes Revamped

Categories: Blogs

Ways of expressing estimates

George Dinwiddie’s blog - Sun, 02/08/2015 - 18:01

The way we express our estimates color both the way we think about the thing being estimated and the way our estimates are heard.

Single value

Quite often, when asked for an estimate, people will give a single value. “How long will this take?” “Three weeks.” If the level of trust is sufficient, and the points of reference are sufficiently aligned, then a single value may be fine. Expressing an estimated value as a single value leaves a lot unsaid, though. How confident are we about that value? If we’re wrong, what might the actual be?

We often find ourselves in trouble when one person gives an estimated value with one set of assumptions, and another person hears it with another set of assumptions. I might stress that my estimate of 2 days for a task is an optimistic one, assuming that no unforeseen problems crop up. You might hear it as an expression of the most likely value, with a small range of error around it. When the communications go further than from one person to the next, the likelihood of misinterpreting the context of assumptions goes way up. If you now communicate my estimate to your boss, they may interpret it as a commitment to that duration. The caveats and warnings tend to fade but the number is remembered.

Over/Under a value

When I learned orienteering in Boy Scouts, one of the lessons was, when finding your way out of the woods by compass, make sure you err to one side. That way, when you reached a road, you’d know which way to turn. If you tried to go directly to your intended destination, you could be on either side when you hit the road.

You can use a similar philosophy when using estimates. Estimating “not more than” or “not less than” can often give enough information to know which way to turn using single point estimation.

Single value with error bars

For some situation, estimating a minimum or maximum value may not be as helpful as a “most likely” value. We can indicate the confidence we have in this value with error bars. Those error bars might be specific minimum and maximum values, though that means we’ve got three separate values to estimate. I’m more likely to use percentages. I’ve often estimated the time required for vaguely described tasks with error bars of -50% and +100%. This seems unbalanced to some people, but looks more reasonable on a logarithmic scale. It also fits with the epidemic over-optimism of software development estimation.


If you’re going to estimate the minimum and maximum possibilities, you might find that the estimated range is enough and you don’t need a most likely value. Beware how you communicate a range estimate, however. It’s all too frequent that the recipient hears just the endpoint they’d prefer. I’ve seen managers complain when a task estimated at 2 to 4 week comes in at 3 weeks, “but you said it could be done in 2 weeks.”

With a confidence level

You can express uncertainty of either a point estimate or a range estimate with a confidence level. “I’m 95% confident that this task can be completed within 2 weeks.” “It’s 95% sure that this work will take from 1 to 3 weeks.”

Sometimes a high confidence level is not what you’d prefer. When estimating user stories to determine how much work fits into a Scrum sprint, for example, using high-confidence estimates will result in taking on less work than you otherwise might attempt. Then, in accordance with Parkinson’s Law, the work expands to fill the allotted time. In such a situation, I recommend estimating at the 50% confidence level. I tell people that they should expect, in the long haul, to run short on time and run short on work in roughly equal amounts.

I don’t know how to estimate confidence levels with a precision that I would trust. I do know that estimating with mathematical models can give you a calculated confidence level. You can then use that confidence level to make decisions with surgical precision based on the odds of the estimation coming true. All of this is still, however, based on the fitness of the mathematical model and the accuracy of the input data.

Confidence levels are easily misunderstood by most people. I’ve often heard people complain that the weather report is inaccurate because it forecast a 30% chance of rain, and it didn’t rain.

Probability distribution

Going further than a confidence level, specifying a probability distribution for our estimate gives us precision at any desired confidence level. If it’s a Gaussian distribution, for instance, we can know their is a 50% chance of the actual being the median value or below. There’s a 97.5% chance of the actual being at or below two standard deviations above the mean.

Of course, the same caveats about fitness of the mathematical models and the accuracy of the input data apply to estimates expressed as probability functions. Empirical data shows that the probability distribution of completion time for a software development project is unlikely to be symmetrical, and therefore the Baussian distribution is a poor model. This leads people to use a Weibull distribution, instead, to model the skew that development time is more likely longer than shorter compared to the median time. The Weibull shape parameter, β, has a dramatic effect on the shape of the distribution, and therefore the fitness.

Unitless measures relative to other estimates

In reaction to the all-too-frequent problems that arise from giving estimates in units of time, sometimes people switch to unitless measures for their estimates. This allows relative estimation between comparable tasks. “This task and that one are about the same size.” Unitless estimation allows the estimate to “float” in absolute terms and be calibrated by past experience. “If we got about 42 units of work done last week, we expect to accomplish about 42 units of work this week.” If the speed of getting work done changes, then only the expectation needs to change; the work does not need to be re-estimated.

The most common unitless measure of the day seems to be story points. These are so-called because they represent the “size” of a functional slice of work called a user story. They’re often restricted to a “modified Fibonacci series” to represent the reduced accuracy of estimation as the size of the story increases.

The human mind is a subtle and wondrous thing. It seems to become better at estimating the size of one story against another when freed from the tyranny of measurements of time. I’ve noticed that teams starting with a completely arbitrary size reference (“Let’s call this fairly small story a ‘2’ and estimate the others relative to it”) seem to achieve consistent sizing more rapidly than those who start with a time-related reference (“Let’s call a story a ‘2’ if it will take about 2 uninterrupted ‘ideal’ hours”).

Sadly, it’s often too tempting for someone, particularly someone with sufficient power in the organization, to calibrate story points back to units of time. This generally negates the advantage of using a unitless measure, as people start thinking in terms of hours instead of points. It’s even worse when the calibration is made to “ideal” hours, as someone will surely complain “Why do the programmers only accomplish 5 hours of story points a day?” <sigh>

Story points are still expressed as numbers, and that tempts people to do more mathematical calculations than their accuracy and precision will reasonably support. The next level of estimate abstraction is to eliminate the numbers. People use many things to stand in for the numbers. One of the most creative is animals. Perhaps the most common is T-shirt sizes, XS, S, M, L, XL. While you can assume that a 10-point story is twice the size of a 5-point, and five times that of a 2-point, you can’t assume such a relationship between a Small, Medium, and Large story. This is another means to free the mind from what it thinks it should know, and let it operate on the subconscious level that often gives better results.

What do you think?

Have I omitted some useful ways to express estimates? Or ways, useful or not, that people tend to use? Have I mischaracterized any of these? Please leave a comment with your thoughts.

Categories: Blogs

Are agile trainers agile?

Scrum Breakfast - Sun, 02/08/2015 - 11:39
There are literally hundreds if not thousands of people out there who will train you to do Agile (and some will even try to convince you to be Agile). Some of them are certified, some are not. How many of them apply Agile to their own profession? I believe the answer is "not many," and I have realized that I was not one of them. This a-ha moment help me refine the purpose of my CST mentorship program.

When people say "Agile", most people are referring to the four values of the Agile Manifesto. While these are important, I believe the fundamental definition of Agility is contained not the four values, but the first statement: We are uncovering better ways of developing software by doing it and helping others do it. (emphasis added).

I don't develop software, I train people to do Scrum. Actually, I like to believe I enable them to turn their current project into their best project ever, so maybe this "training Scrum" is too limiting. Hmm... let's not go overboard just yet! So what would my manifesto look like? Here is the first draft:
We are uncovering better ways of teaching Scrum, by doing it and helping others to do it! -- Peter StevensThis has become the overarching goal of my CST Mentorship idea. Not just to get you through the TAC, but to create a community of like minded Agile trainers, who help each other to become better trainers, and help others to do the same.  It is no longer just a CST mentorship program, but a CST Mentoring Network.

P.S. I went looking for trainers who are active and transparent about mentoring. I have only found two (including myself):

Does anyone else belong on this list? Please let me know!

Categories: Blogs

The Great Personal Development Quotes Collection Revamped

J.D. Meier's Blog - Sat, 02/07/2015 - 23:54

“Knowing others is intelligence.  Knowing yourself is true wisdom.  Mastering others is strength.  Mastering yourself is true power.” -- Lao Tzu

A while back I put together a comprehensive collection of personal development quotes.   It’s a combination of the wisdom of the ages + modern sages.   It was time for a revamp.  Here it is:

The Great Personal Development Quotes Collection

It's a serious collection of personal development quotes and includes lessons from the likes of Buddha, Covey, Emerson,  Gandhi, Robbins, Ziglar, and more.

Personal Development is a Way to Realize Your Potential

Personal development is a process for life where you improve your awareness, your skills, your abilities, and your potential.  Personal development shapes your growth by developing your strengths, reducing your liabilities, and expanding what you’re capable of.

You improve your potential through self-awareness, habits, practice, and feedback.

Awareness is Half the Battle

A big part of personal development is simply awareness.  For example, when you know your Myers & Briggs Personality Type, you gain insight into whether you outwardly or inwardly focused, how you prefer to take in information, how you prefer to make decisions, and how you prefer to live your outer life.

Aside from better understanding your own patterns, you can also use it to understand other people’s behavior preferences, and you can adapt your style.  If you see somebody staring blankly at you during your presentation, it doesn’t mean they aren’t engaged.  They might just be an introvert processing the information in their own quiet way.

If you know your Conflict Style, you can tailor and adapt it to the situation, as well as better understand the mode that others are operating in.

There are many models and tools for self-awareness, but the goal is the same:  learn how to be more effective in more situations based on your individual strengths, abilities, and experience.

Action is the Other Half

Personal development is a verb.   You need to take action.  All the knowledge in the world doesn’t matter if you don’t apply it.  Even thoughts are habits that we haven’t learned how to measure.  When you apply what you learn, you can adjust what you learn based on feedback and results.

If you keep in mind that personal development is about continuously improving your thinking, feeling, and doing, then it’s easier to stay focused and to evaluate your results.

You can also approach personal development in a number of ways.  Just like martial arts, there are hard-styles and there are soft-styles.  In my experience, it helps to balance and blend hard-core skill building along with building the soft skills, especially interpersonal skills and your emotional intelligence.

Personal Development Requires a Growth Mindset

If you want to grow, you have to believe you can.

If you adopt a Growth Mindset, you can create a love of learning and a resilience that is the basis of great accomplishment in every area of work and life.

In the book, Mindset: The New Psychology of Success, author Carol Dweck shares a lot of science and stories around how our mindset limits or enables our growth.  If we believe that our abilities are fixed traits, and that we are either good or bad at something, then we have a Fixed Mindset.

If, on the other hand, you believe that you can get better through skills development, then you have a Growth Mindset.

If you’ve ever been in any sort of elite training, or specialized skills development or had a great mentor that provides deep feedback, it should be more than obvious to you how much growth and greatness is possible.

Adapting is the Key to Personal Development Success

So if you have a Growth Mindset, and you practice personal development, and you develop your self-awareness, then what will hold you back?

Simple.   The inability or lack of willingness for you to change your approach.

Darwin taught us that nature favors the flexible and Einstein said that doing the same thing over and over again and expecting different results is the definition of insanity.

And yet, how many people get stuck in a rut or hold themselves back through limiting thought patterns or behaviors?

One of the greatest things you can possible do for your future success is to learn how to change your approach with skill.

I could say so much more about personal development but at this point, I’d rather share what some of the greatest giants in personal development have had to say.  

Use The Great Personal Development Quotes Collection to stand on the shoulders of giants, and see further, as you look inward and upward.

And if you want a jumpstart in agile personal development, check out my best-selling book on productivity:  Getting Results the Agile Way.   It’s a simple system for meaningful results, and  it’s a way to use personal development to think better, feel better, and do better in all areas of your life.

Categories: Blogs

I've moved my blog over to http:/

Agile Coaching - Rachel Davies - Sat, 02/07/2015 - 20:40
I've moved my blog over to
Categories: Blogs

Automatically setting up pipelines

Putting the tea into team - Ivan Moore - Sat, 02/07/2015 - 14:05
Scripting the set up your continuous integration (CI) server is better than clicky clicky, but it might be possible to do even better. If you have many pipelines that are very similar then you might be able to fully automate their set up. A bit like having your own, in house version of Travis CI.

This article will use the GoCD terms "pipeline" and "stage" (a pipeline is somewhat like a "job" Jenkins, and a pipeline comprises one or more stages).

This article describes (at a very high level) the system my colleague Hilverd Reker and I have set up to automatically create pipelines. This has built on experience I gained doing something similar with Ran Fan at a previous client, and being the "customer" of an automated CI configuration system at another previous client.
InceptionWe have a pipeline in our CI server to automatically create the pipelines we want. We have called this "inception", after the film - I think Ran Fan came up with the name.

The inception pipeline looks for new things to build in new repositories, and sub directories within existing repositories, and creates pipelines as appropriate (using gomatic). (The inception process that Ran Fan and I wrote previously, looked for new things to build within "one large repo" (maybe the subject of a future blog article), and new branches of that repository).

The advantage of having this fully automated, compared to having to run a script to get the pipeline set up, is that it ensures that all pipelines get set up: none are forgotten and no effort is required.

Our inception job sets up a pipeline with only one stage, the bootstrap stage, which configures the rest of the pipeline. This keeps the inception job simple.
The bootstrap stageSome of the configuration of a pipeline depends upon the files in the repository that the pipeline is for. By making the first stage in the pipeline the bootstrap stage, it can configure the pipeline accurately for the files as they exist when the pipeline runs. If a pipeline is configured by the inception job, or by running a script, rather than a bootstrap stage, then its configuration will not reflect the files in the repository when they change, but rather how they were at the time the inception job, or script, ran. This would result in pipelines failing because they are not set up correctly for the files they are trying to use; hence we have the bootstrap as part of the pipeline itself to solve that problem.
Implementation notesOur bootstrap stage only alters the configuration of the pipeline if it needs to: it runs very quickly if no changes are needed. GoCD handles changes to the configuration of pipeline well. After the bootstrap stage has run, the subsequent stages run in the newly configured, or reconfigured, pipeline as expected. GoCD also handles the history of a pipelined reasonably well (but not always getting it right), even when it's configuration changes over time.
Example What would help right now would be an example - but that'll take time to prepare; watch this space (patiently) ...

Copyright ©2015 Ivan Moore 
Categories: Blogs

The Elephant in the Room (A Performance Review Conundrum)

Illustrated Agile - Len Lagestee - Fri, 02/06/2015 - 18:30

This was a question posted as a reply to the post Make Performance Reviews Meaningful. If you have questions of your own, feel free to reply to any post or submit your question on our Ask Anything page. One big question though: what do you do in the big reviews if an employee has had […]

The post The Elephant in the Room (A Performance Review Conundrum) appeared first on Illustrated Agile.

Categories: Blogs