Skip to content

Blogs

The Edible Birthday

Portia Tung - Selfish Programming - Mon, 09/29/2014 - 21:33

Birthday Cake

I’m a September baby and this year, I treated my friends at work to the most scrumptious cake I’ve ever seen. What better way to remind us of transformative journeys along the Yellow Brick Road than with the Rainbow Cake by Hummingbird Cafe.

Folks ummed and ahhed at the sight of the multi-coloured layers of this beautiful cake only to be further and pleasantly surprised by the bubble gum flavoured icing as they savoured their slice.

“If I still wrote software, this would be the kind of software I’d create,” I mused, drunken on sugary goodness.

“Don’t you think that would smack of over-engineering?” remarked a fellow cake-connoisseur.

Of course, what I really meant to say is that I marvel at the thought of creating something so thoughtful and thought-provoking as the Rainbow cake. A work of exquisite (and, optionally, edible) beauty that would brighten the world and remind us of what passion, creativity and craftsmanship can produce.

All this serves as a timely reminder that we need to live our dreams to make them come true.

Here’s to enjoying the rainbows on your journey of a lifetime. Happy Birthday one and all!

Categories: Blogs

Combining PRINCE2 with Agile

TV Agile - Mon, 09/29/2014 - 20:01
PRINCE2 and Agile are now both mainstream and many organizations are combining these two approaches but with varying degrees of success. How can you benefit from linking these two approaches which, on the face of it, may not be seen as complementary? This presentation covers: * What are the relative strengths of each approach? * […]
Categories: Blogs

The Future of Jobs

J.D. Meier's Blog - Mon, 09/29/2014 - 17:46

Will you have a job in the future?

What will that job look like and how will the nature of work change?

Will automation take over your job in the near future?

These are the kinds of questions that Ruth Fisher, author of Winning the Hardware-Software Game, has tackled in a series of posts.

I wrote a summary post to distill her big ideas and insights about the future of jobs in my post:

The Future of Jobs

Fisher has done an outstanding job of framing out the landscape and walking the various arguments and perspectives on how automation will change the nature of work and shape the future of jobs.

One of the first things you might be wondering is, what jobs will automation take away?

Fisher addresses that.

Another question is, what new types jobs will be created?

While that’s an exercise for the reader, Fisher provides clues based on what industry luminaries have seen in terms of how jobs are changing.

The key is to know what automation can and can’t do, and to look at the pattern of work in terms of what’s better suited for humans, and what’s better suited for machines.

As one of my mentors puts it, “If the work can be automated, it’s not human.”

He’s a fan of people doing creative, non-routine work, where they can thrive and shine.

As I take on work, or push back on work, I look through a pretty simple lens:

  1. Is the work repetitive in nature? (in which case, something that should be automated)
  2. Is the work a high-value activity? (if not, why am I doing non high-value activities?)
  3. Does the work create greater capability? (for me, the team, the organization, etc.)
  4. Does the work play to my strengths? (if not, who is a better resource or provider.  You grow faster in your strengths, and in today’s world, if people aren’t giving their best where they have their best to give, it leads to a low-impact team that eventually gets out-executed, or put out to Pasteur.)
  5. Does the work lead to world-class impact?  (When everything gets exposed beyond the firewall, and when it’s a globally connected ecosystem, it’s really important to not only bring your A-game, but to play in a way where you can provide the best service in the world for your specific niche.   If you can’t be the best in your niche in a sustainable way, then you’re in the wrong niche.)

I find that by using this simple lens, I tend to take on high-value work that creates high-impact, that cannot be easily automated.  At the same time, while I perform the work, I look for way to turn things into repetitive activities that can be outsources or automated so that I can keep moving up the stack, and producing higher-value work … that’s more human.

Categories: Blogs

Introducing SAFe for Lean Systems Engineering Big Picture 0.21

Agile Product Owner - Mon, 09/29/2014 - 17:41

Hi,

In an earlier post, we announced the development of a new solution framework: SAFe for Lean Systems Engineering (SAFe LSE for short). Work continues at a pretty good pace, and the team (mostly Dean, Harry, Inbar, Alex, Regina so far) have been pretty busy putting up the new site, developing content, and of course, working on the Big Picture for SAFe LSE.

As we often discuss in SPC class, the BP serves as the domain model for the framework, as it it identifies the people that do the work, their major activities, and the work products that capture decisions and help guide the flow of work.

To that end, attached is “v 0.21″ of the SAFe LSE BP, being the 21st internal revision of this diagram. It’s far from done (SAFe reached over 100 revs before I stopped counting) but we think it tells an adequate story to start with. Of course, it isn’t fully self-explanatory, for that we need content and the website, but we think those building big complex systems can get an idea where we are headed with this version.

SAFe for Lean Systems Engineering Big Picture v0.21

SAFe for Lean Systems Engineering Big Picture v0.21

As for the near-future roadmap, we will go live with a preview version sometime in November. That one will be fully open for comments, so all can participate in adding value and criticism, as the case may be.

We do look forward to your input, and be assured that we have now fully committed to this initiative, so there will be a first GA release of SAFe for Lean systems Engineering sometime in 2015.

– Dean

PS: If you check the earlier post, you’ll see that Manifesto, which will also be elaborated with hyperlinked SAFe LSE principles, has also been updated, based on a lot of feedback we have garnered so far

PPS: We are also building a new 3-day training course:

Leading SAFe LSE: Leading Lean Systems Development with 
SAFe for Lean Systems Engineering.

The first version of this course will be delivered the first week in February, in the Boulder training center. We should have that course available for registration later this week.

Categories: Blogs

Scale Agile With Small-World Networks Posted

Johanna Rothman - Mon, 09/29/2014 - 16:59

I posted my most recent Pragmatic Manager newsletter, Scale Agile With Small-World Networks on my site.

This is a way you can scale agile out, not up. No hierarchies needed.

Small-world networks take advantage of the fact that people want to help other people in the organization. Unless you have created MBOs (Management By Objectives) that make people not want to help others, people want to see the entire product succeed. That means they want to help others. Small-world networks also take advantage of the best network in your organization—the rumor mill.

If you enjoy reading this newsletter, please do subscribe. I let my readers know about specials that I run for my books and when new books come out first.

Categories: Blogs

Agile and Predictability

James Shore - Mon, 09/29/2014 - 10:00
29 Sep 2014 James Shore/Blog

Over on the AgilePDX mailing list, there's an interesting conversation on making predictions with Agile. It started off with Michael Kelly asking if Agile can help with predictability. Here's my response:

It's entirely possible to make predictions with Agile. They're just as good as predictions made with other methods, and with XP practices, they can be much better. Agile leaders talk about embracing change because that has more potential value than making predictions.

Software is inherently unpredictable. So is the weather. Forecasts (predictions) are possible in both situations, given sufficient rigor. How your team approaches predictions depends on what level of fluency they have.

One-star teams adapt their plans and work in terms of business results. However, they don't have rigorous engineering practices, which means their predictions have wide error bars, on par with typical non-Agile teams (for 90% reliability, need 4x estimate*). They believe predictions are impossible in Agile.

Two-star teams use rigorous engineering practices such as test-driven development, continuous integration, and the other good stuff in XP. They can make predictions with reasonable precision (for 90% reliability, need 1.8x estimate*) They can and do provide reliable predictions.

Three- and four-star teams conduct experiments and change direction depending on market opportunities. They can make predictions just as well as two-star teams can, but estimating and predicting has a cost, and those predictions often have no real value in the market. They often choose not to incur the waste of making predictions.

So if a company were to talk to me about improving predictability, I would talk to them about what sort of fluency they wanted to achieve, why, and the investments they need to make to get there. For some organizations, *3 fluency isn't desired. It's too big of a cultural shift. In those cases, a *2 team is a great fit, and can provide the predictability the organization wants.

I describe the "how to" of making predictions with Agile in "Use Risk Management to Make Solid Commitments".

*The error-bar numbers are approximate and depend on the team. See the "Use Risk Management" essay for an explanation of where they come from.

Categories: Blogs

R: Filtering data frames by column type (‘x’ must be numeric)

Mark Needham - Mon, 09/29/2014 - 07:46

I’ve been working through the exercises from An Introduction to Statistical Learning and one of them required you to create a pair wise correlation matrix of variables in a data frame.

The exercise uses the ‘Carseats’ data set which can be imported like so:

> install.packages("ISLR")
> library(ISLR)
> head(Carseats)
  Sales CompPrice Income Advertising Population Price ShelveLoc Age Education Urban  US
1  9.50       138     73          11        276   120       Bad  42        17   Yes Yes
2 11.22       111     48          16        260    83      Good  65        10   Yes Yes
3 10.06       113     35          10        269    80    Medium  59        12   Yes Yes
4  7.40       117    100           4        466    97    Medium  55        14   Yes Yes
5  4.15       141     64           3        340   128       Bad  38        13   Yes  No
6 10.81       124    113          13        501    72       Bad  78        16    No Yes

filter the categorical variables from a data frame and

If we try to run the ‘cor‘ function on the data frame we’ll get the following error:

> cor(Carseats)
Error in cor(Carseats) : 'x' must be numeric

As the error message suggests, we can’t pass non numeric variables to this function so we need to remove the categorical variables from our data frame.

But first we need to work out which columns those are:

> sapply(Carseats, class)
      Sales   CompPrice      Income Advertising  Population       Price   ShelveLoc         Age   Education 
  "numeric"   "numeric"   "numeric"   "numeric"   "numeric"   "numeric"    "factor"   "numeric"   "numeric" 
      Urban          US 
   "factor"    "factor"

We can see a few columns of type ‘factor’ and luckily for us there’s a function which will help us identify those more easily:

> sapply(Carseats, is.factor)
      Sales   CompPrice      Income Advertising  Population       Price   ShelveLoc         Age   Education 
      FALSE       FALSE       FALSE       FALSE       FALSE       FALSE        TRUE       FALSE       FALSE 
      Urban          US 
       TRUE        TRUE

Now we can remove those columns from our data frame and create the correlation matrix:

> cor(Carseats[sapply(Carseats, function(x) !is.factor(x))])
                  Sales   CompPrice       Income  Advertising   Population       Price          Age    Education
Sales        1.00000000  0.06407873  0.151950979  0.269506781  0.050470984 -0.44495073 -0.231815440 -0.051955242
CompPrice    0.06407873  1.00000000 -0.080653423 -0.024198788 -0.094706516  0.58484777 -0.100238817  0.025197050
Income       0.15195098 -0.08065342  1.000000000  0.058994706 -0.007876994 -0.05669820 -0.004670094 -0.056855422
Advertising  0.26950678 -0.02419879  0.058994706  1.000000000  0.265652145  0.04453687 -0.004557497 -0.033594307
Population   0.05047098 -0.09470652 -0.007876994  0.265652145  1.000000000 -0.01214362 -0.042663355 -0.106378231
Price       -0.44495073  0.58484777 -0.056698202  0.044536874 -0.012143620  1.00000000 -0.102176839  0.011746599
Age         -0.23181544 -0.10023882 -0.004670094 -0.004557497 -0.042663355 -0.10217684  1.000000000  0.006488032
Education   -0.05195524  0.02519705 -0.056855422 -0.033594307 -0.106378231  0.01174660  0.006488032  1.000000000
Categories: Blogs

Team Genetics

Agile Tools - Mon, 09/29/2014 - 07:41

dna-163710_640

Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.

Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.

“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”

While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.

I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.

When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.

Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.

“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”

So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…


Filed under: Agile, Lean, Process, Scrum, Swarming, XP Tagged: Agile, evolution, Extreme Programming, Kanban, meme, no estimates, Process, software development, XP
Categories: Blogs

Broadcast Communication

Agile Tools - Sun, 09/28/2014 - 04:56

SONY DSC

In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.

What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.

Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.

Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.

There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.

A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:

  • The Scrum of Scrums or other program or portfolio meetings
  • Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
  • Attending other forums, other teams status meetings
  • Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.

If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.


Filed under: Agile, Process, Scrum, Swarming, Teams Tagged: communication, information radiators, one way broadcast, Swarming
Categories: Blogs

1. Capitalisation target; 2. ???; 3. Profit!

The organisation has a capitalisation target.

Everyone encourages managers to increase the capitalisation of their areas.  If they don't, they won't get funded.

The simplest way to increase capitalisation rate is simply changing numbers in spreadsheets.  This is mostly independent of whether or not the work is creating an asset because it's easier to move a number than it is to argue.
I've been told that from a corporate finance perspective, the priority is:
  1. Appropriate accounting of capital and operating expense
  2. Effective use of financial investment to achieve strategic goals
"How might we meet our capitalisation target?" is a question that leads organisations away from either of those goals.
Instead, if we want appropriate accounting, we might ask..."How might we improve the accuracy of our accounting?"This might lead to...
  • Training sessions, guides, etc. on appropriate capitalisation
  • Integration with tooling
  • Only assessing capitalisation after delivery of the assets.  That is, operating using OPEX and only journalling to CAPEX upon release.  I'd call this "as-built accounting".
Instead, if we want to have more effective financial investment, we would just ask that question..."How might we be more effective with our financial investment?"This might lead to...

  • Clearer communication of strategic intent
  • Collective prioritisation of the portfolio
  • Smaller batch sizes to allow for staged investment
  • More sophisticated ways of assessing investments (e.g. Cost of Delay)
Categories: Blogs

Swarming Roles

Agile Tools - Sat, 09/27/2014 - 07:55

athletes-ball-football-2199-828x550

So far in this series I have covered the values and principles of the swarming methodology. Now let’s talk about roles on swarming teams. In nature, when you look at swarms, flocks and schools there are all kinds of specialization. The nature of the roles can be fixed (i.e. workers and queens) or they can be dynamic (foraging, nursing, etc.). So there are a very broad range of roles that we can find in the animal world. Given those models, there are a few things we can identify as critical to swarming teams:

  • Swarms don’t have Managers, Masters or Owners
  • Swarms have radical diversity
  • Membership is not fixed

There are none of the typical command and control structures to be found on a swarming team. There is no manager. There is no owner. There is no one person making any of the decisions for the group. Swarming doesn’t work without complete equality. That doesn’t mean there can’t be leaders, they are still necessary, but it is only leadership by virtue of their ideas, not any sort of hierarchy or power relationship.

Swarms require diversity. Swarm based decision making is enabled by diversity in the group. Without that diversity, the swarm is likely to have too narrow a perspective and come up with poor answers. This comes from the wisdom of crowds – it doesn’t work without diversity. True diversity is rare in our business. I’m not talking about just race and sex (although more diversity there is necessary), I’m actually talking about a diversity of knowledge and interests. We need people who aren’t software engineers on our teams. Anyone can play: the admin, the fisherman, the librarian, the doctor and the engineer. I think of this as radical diversity.

Finally, the membership of the team doesn’t stay the same. It ebbs and flows with the popularity of the project and the ideas that are being worked on. Anyone can come or go on any given day. They are able to follow their passions where ever they may go. Swarm teams can recruit, sell, and dissipate completely. Nothing about the membership on swarming team is mandatory.

 


Filed under: Agile, Swarming Tagged: diversity, no managers, principles, radical diversity, roles, Swarming, values
Categories: Blogs

Neo4j: COLLECTing multiple values (Too many parameters for function ‘collect’)

Mark Needham - Fri, 09/26/2014 - 22:46

One of my favourite functions in Neo4j’s cypher query language is COLLECT which allows us to group items into an array for later consumption.

However, I’ve noticed that people sometimes have trouble working out how to collect multiple items with COLLECT and struggle to find a way to do so.

Consider the following data set:

create (p:Person {name: "Mark"})
create (e1:Event {name: "Event1", timestamp: 1234})
create (e2:Event {name: "Event2", timestamp: 4567})
 
create (p)-[:EVENT]->(e1)
create (p)-[:EVENT]->(e2)

If we wanted to return each person along with a collection of the event names they’d participated in we could write the following:

$ MATCH (p:Person)-[:EVENT]->(e)
> RETURN p, COLLECT(e.name);
+--------------------------------------------+
| p                    | COLLECT(e.name)     |
+--------------------------------------------+
| Node[0]{name:"Mark"} | ["Event1","Event2"] |
+--------------------------------------------+
1 row

That works nicely, but what about if we want to collect the event name and the timestamp but don’t want to return the entire event node?

An approach I’ve seen a few people try during workshops is the following:

MATCH (p:Person)-[:EVENT]->(e)
RETURN p, COLLECT(e.name, e.timestamp)

Unfortunately this doesn’t compile:

SyntaxException: Too many parameters for function 'collect' (line 2, column 11)
"RETURN p, COLLECT(e.name, e.timestamp)"
           ^

As the error message suggests, the COLLECT function only takes one argument so we need to find another way to solve our problem.

One way is to put the two values into a literal array which will result in an array of arrays as our return result:

$ MATCH (p:Person)-[:EVENT]->(e)
> RETURN p, COLLECT([e.name, e.timestamp]);
+----------------------------------------------------------+
| p                    | COLLECT([e.name, e.timestamp])    |
+----------------------------------------------------------+
| Node[0]{name:"Mark"} | [["Event1",1234],["Event2",4567]] |
+----------------------------------------------------------+
1 row

The annoying thing about this approach is that as you add more items you’ll forget in which position you’ve put each bit of data so I think a preferable approach is to collect a map of items instead:

$ MATCH (p:Person)-[:EVENT]->(e)
> RETURN p, COLLECT({eventName: e.name, eventTimestamp: e.timestamp});
+--------------------------------------------------------------------------------------------------------------------------+
| p                    | COLLECT({eventName: e.name, eventTimestamp: e.timestamp})                                         |
+--------------------------------------------------------------------------------------------------------------------------+
| Node[0]{name:"Mark"} | [{eventName -> "Event1", eventTimestamp -> 1234},{eventName -> "Event2", eventTimestamp -> 4567}] |
+--------------------------------------------------------------------------------------------------------------------------+
1 row

During the Clojure Neo4j Hackathon that we ran earlier this week this proved to be a particularly pleasing approach as we could easily destructure the collection of maps in our Clojure code.

Categories: Blogs

Making an Impact with Kanban Thinking

AvailAgility - Karl Scotland - Fri, 09/26/2014 - 16:26

This post pulls together a number of ideas  on impact into a single place, and will become the content for a page in Impact on the Kanban Thinking site.

What is Impact

Outputs creates Outcomes which have Impact.

Designing a Kanban System involves the evolution and discovery of a good design. It cannot be pre-determined in advance. Thus instead of defining a future-state and working towards it, we start with the current-state and work away from it, exploring and assessing different alternatives. Each output of a design iteration will create different outcomes, and those that improve the system can be said to have a positive impact, while those that worsen the system have a negative impact.

Impact, therefore, describes the disposition of the system, or its tendency to behave in a certain way. Rather than defining a planned destination, impact points to the desired direction, such that we can check whether any changes are moving us towards or away from the direction we want to be heading. Impact can be assessed by using narrative techniques to capture stories about utopian (and dystopian) futures, and subsequently asking whether an outcome is likely to lead to more of the positive stories and fewer of the negative stories.

Describing Impacts

When imagining what impacts would be desirable, its easy for our experiences and biases to lead us to narrow our thinking and prematurely converge on only one particular type of impact. To avoid this, and encourage diversity in exploring a wide variety of potential impacts, Kanban Thinking describes three types to consider, giving different perspectives.

  • Flow. This is Doing the Thing Right. Stories will be primarily related to the process, efficiency and reliability.
  • Value. This is Doing the Right Thing. Stories will be primarily related to the product, effectiveness and validity.
  • Potential. This is Doing the Thing Sustainably. Stories will be primarily related to people, euphoria and flexibility.
Impacts as Triads

When exploring the impacts, it will become apparent that there is not always an obvious and neat mapping to either flow, value or potential. Thus, the three impacts can be thought of as a triad, with each being a vertex of a triangle.

Triads are concept I learned from Dave Snowden and used by the Cognitive Edge Sensemaker Suite (note that they have a patent associated with this), where a triangle is used as a measuring instrument to assess against three parameters. By using triads, impacts can be placed relative to where they have the strongest affinity, without having to decide on any one in particular. Imagine an impact being connected to each vertex with elastic. The greater the affinity to a vertex, the greater the tension, with the final position being a result of the combination of all three. Thus the story in the triad below has the strongest affinity with the Flow vertex. The next strongest is Potential, with Value being the weakest.

Impact Triad

While triads are an approach not directly supported by the canvas in its current form, the deliberate choice of words to describe each impact creates multiple possible triads which could be explored. Deciding where an impact goes generally requires more thinking, and generates greater dialogue and insight.

FlowValuePotential Thing RightRight ThingThing Sustainably ProcessProductPeople ReliabilityValidityFlexibility EfficiencyEffectivenessEuphoria

Generating lots of utopian (and dystopian) future stories, instrumented with these triads, will generate patterns which can give a sense of where the improvement opportunities are for making an impact.

Example

Here’s an example of thinking about impact from the three perspectives. It is intentionally lacking in direct relevance to minimise the risk of biasing your own answers to the questions.

When I go running, I’m generally wanting to improve my health and fitness. What impact do I want to have?

  • From a Flow perspective, impact could be about pace and speed. I could imagine a utopian future where I can run a 4 minute mile.
  • From a Value perspective, impact could be about distance and stamina. I could imagine a utopian future where I can run 100 miles.
  • From a Potential perspective, impact could be about friendship and community. I could imagine a utopian future where I am the president of a local running club.

None of these are mutually exclusive. If I can run a 4 minute mile, then there is a high likelihood that I’ll be involved in a running club, and training longer distances as well. However, explicitly exploring the different perspectives avoids me just focussing on one thing such as speed, to the detriment of friendship or stamina.

What stories would you like to tell about the impact your kanban system makes in the future?

Categories: Blogs

Refurbishing a Mail Slot and Doobell

Radyology - Ben Rady - Fri, 09/26/2014 - 15:01
When I moved into my house, the mailbox was in pretty sorry shape. It was corroded, and the mail flap was stuck open. On top of that, it had an integrated doorbell that didn't work. Lastly, the entire border of... Ben Rady
Categories: Blogs

When everything is “most important” … nothing is

Derick Bailey - new ThoughtStream - Fri, 09/26/2014 - 13:00

inbox-overflow

It can be difficult to prioritize -

especially when everything is highest priority and most important.

But the truth is, when everything is the highest priority or the most important thing you have to do, then nothing is. That doesn’t mean you don’t have important things to do. It only means that your time and priorities are not being managed correctly. The result will be floundering around, trying to figure out what to do, and generally being stuck in fire-fighting mode where the only thing you can focus on is the thing that is currently on fire.

This isn’t a good place to be.

Learning To Say No… Again

I’ve dealt with this issue in the past, and it seems to be coming up again in my life. I’ve had to say no to more and more things recently, because I seem to have been stuck in fire-fighting mode for far too long. So I unloaded a few of the “important” things and sat down to try and organize my time and priorities.

Starting With My “Every Week” Things

Organizing my time was easy at first. I have a list of things that always happen every week:

  • Client work (for my 1 client)
  • This weekly email
  • WatchMeCode episode release
  • family things, etc

These are things that always happen in my week – they are clearly the highest priorities for me.

But after that, I was getting stuck in the cycle of trying to figure out what to do next and not being able to focus or set priorities. Should I work on more screencasts? Should I work on SignalLeaf? Should I do marketing for either of those? Do I need to blog more on DerickBailey.com? Or on SignalLeaf? What about … the list was getting overwhelming, and I wasn’t getting anything done.

Focus: 1 Week At A Time

For a while, all of my projects suffered. I was jumping back and forth between too many things in a given week or given day. Doing this was causing everything to fall further and further behind because I couldn’t focus. Then Josh and John, from my entrepreneur group, suggested I try to focus 1 week at a time.

Once I had my “every week” items scheduled I needed to pick one project to work on each week. At the beginning of a week, I plan out what I am going to do for the week on that one project. Other projects and responsibilities get pushed to the side during that week, so that I can focus and stay focused.

For example, one week I’ll work on SignalLeaf. The next week, I’ll work on WatchMeCode. After that, back to SignalLeaf or maybe some other thing that came up recently. Somewhere in the mix, I’ll decide that I need to move DerickBailey.com forward, and I’ll plan a week of working on that.

Setting these week long sprints of work on a given project is helping me move every project forward, instead of wondering when any given project will be moved.

How It Has Helped So Far

I’ve only been doing this for 2 weeks now, as I’m writing this to you. But so far it has helped me a lot. My 2 weeks of focus have allowed me to make very large leaps and bounds forward on all fronts of that week’s project. I’m no longer trying to decide between projects – I have an entire week in which I will work on one of them.

Being able to focus like this has helped out every project I have, already – even if I’ve only planned to work on a project and haven’t actually done the work yet. At least now, I have a plan for it instead of just worrying about when I’ll get to it.

The Future Of Focus

This week I’m focusing on WatchMeCode, and next week will be focused on a presentation for a conference. After that, I’ll get back to SignalLeaf…. after that… well, I’m not planning that far ahead, yet. And I’m ok with that. The further out I go, the less specific my plans need to be. I can have a general idea of where I’m heading more than a month from now, but I only need to know what my next 2 or 3 weeks look like.

That doesn’t mean I won’t at least think that far ahead. It only means that I don’t have to write it down or commit to it yet. I’m sure there will be times when I do have a specific deadline for something (like a conference) and I’ll need to plan that far ahead. But for now, I’m going to run with only 1 or 2 weeks planned and see how it goes.

Still An Experiment. Looking To Improve.

I may have only been doing this for 2 weeks so far, but right now I’m feeling like this is going to be the way that helps me move forward with all of my projects (in addition to reducing the number of projects I have, that is).

But even with this tool in place, I know I can still do better. What tools and techniques do you have in place to help manage your time and focus? I’d love to hear about how you handle things. Leave a comment below, and let me know!

– Derick

     Related Stories 
Categories: Blogs

Swarming Principles

Agile Tools - Fri, 09/26/2014 - 08:56

animal-beetle-insect-329-825x550

In an earlier post I introduced a set of values that might be used to guide swarming teams. Values are a good start. They provide very broad guidelines to give teams guidance when making big picture decisions. Principles help give more specific guidance. So here are a few principles that are aimed at guiding teams practicing swarming as a discipline.

Swarming Principles

  • The most important thing I can do is whatever I am most passionate about today
  • Prefer one way broadcast over two way communication
  • Using agreed upon protocols enhances the effectiveness of our communication and decision making

The first principle tells us that we need to be fully engaged in whatever we care most about. That means that people move to where ever they have the most interest. Teams are spontaneously formed dynamic entities that are composed of people who share a common passion.

The second principle tells us that we not only need to communicate, we need to radiate. Information needs to be broadcast exuberantly without reservation or hesitation.

The third principle tells us that one of the foundations for emergent behavior is in simple protocols. We need to be explicit and disciplined in how they are applied and we need to be always seeking new protocols to add to the mix.


Filed under: Agile, Swarming Tagged: methodology, principles, Swarming, values
Categories: Blogs

Es liegt an dir, was du aus der Arbeitswelt machst

Scrum 4 You - Fri, 09/26/2014 - 07:45

Das Team von Boris Gloger Consulting besteht nicht nur aus Beraterinnen und Beratern. Unser „Backbone“ ist im wahrsten Sinne des Wortes das Rückgrat, das dem Unternehmen seine Stabilität gibt: Die Kolleginnen kümmern sich um die Finanzen, ums Marketing und um den Kontakt mit BewerberInnen und Freelancern. Seit August unterstützt Diana Eiswirt das Team. Sie absolviert bei uns ihre Ausbildung zur Kauffrau für Büromanagement – unser allererster Azubi, darauf sind wir sehr stolz! Diana hat sich bereit erklärt, das Arbeitsleben für einen Blogartikel aus ihrer Sicht als junge Einsteigerin in die Arbeitswelt zu betrachten. Danke Diana!

Man sollte nicht auf Mitmenschen hören, die sagen: „Du wirst die Schulzeit noch vermissen.“ Es ist zwar gut möglich, dass dies passiert, wenn man z.B.eine tolle Schulzeit mit vielen Freunden und Ausflügen hinter sich hat, aber einen großen Unterscheid zwischen Schule und Arbeit sehe ich bislang noch nicht. Seit ich am 01.08.2014 bei Boris Gloger Consulting meine Ausbildung begonnen habe, weiß ich, dass Arbeiten auch Spaß machen kann.

In der Schule lernt man, aber in der Arbeit gibt es auch noch genügend zu lernen.
In der Schule hast du deine Freunde, aber du kannst deine Kollegen auch zu deinen Freunden machen.
Man muss für die Schule morgens früh raus, das muss man bei der Arbeit auch.

Wo liegt also der große Unterschied? Ich finde, so viel anders ist es gar nicht. In der Schule geben die Lehrer die Anweisungen und Aufgaben, in der Arbeit wird der Lehrer durch einen Chef ersetzt – es funktioniert also nach dem selben Prinzip. Ob du letztendlich die Schulzeit vermisst, liegt in deiner Hand und daran, was du aus der Arbeitswelt machst. Es ist ein neuer und wichtiger Lebensabschnitt, um den keiner drumherum kommt, früher oder später muss da jeder durch. Doch dieser Abschnitt lässt uns nochmals mehr erwachsen werden und anders denken.

Als Auszubildende habe ich mittlerweile schon meine festen Aufgaben, die ich zu erledigen habe, und trotzdem lerne ich so gut wie jeden Tag etwas Neues – das bringt Abwechslung in mein Berufsleben. Abwechslung ist für mich gut, da es das Arbeiten nicht langweilig werden lässt.

Momentan gehören zu meinen Aufgaben:

  • Reisekosten bearbeiten
  • die Kontakte in unserem CRM-Programm verwalten
  • Trainees für Trainings anmelden und Bestätigungen versenden
  • Zertifizierungen bearbeiten
  • Vorlagen erneuern bzw. in unser neues Corporate Design bringen

Bis jetzt ist es zwar noch nichts Großes, das ich eigenständig machen kann, aber trotzdem macht es mir Spaß! Es macht Spaß, auch wenn es nicht immer ganz einfach war: Immerhin musste ich erst einmal mit den Programmen zurechtkommen. Doch das wird von Tag zu Tag besser und ich werde immer sicherer.

Ich freue mich jeden Tag aufs Neue, zur Arbeit zu kommen, um Neues zu lernen. Ich hoffe, es bleibt mein ganzes Berufsleben so – dass meine Arbeit mir Freude bereitet und ich jeden Tag gerne dorthin gehe.
Sicherlich wird es den einen oder anderen Tag geben, der nicht so läuft, wie ich es mir gewünscht habe, und dennoch wird mich das nicht abschrecken. Arbeiten muss nicht so schlimm sein, wie viele es sagen. Arbeit ist das, was man daraus macht!

Man sollte sich immer fragen:

  • Mache ich meine Arbeit gerne?
  • Ist es das, was ich bis zu meiner Rente gerne jeden Tag aufs Neue machen will?

Warum sollte Arbeit eigentlich Spaß machen? Aus dem einfachen Grund heraus, weil wir einen großen Teil unseres Lebens damit verbringen! Es ist es für den Mitarbeiter selbst, aber auch für den Chef nur von Vorteil, wenn jeder Angestellte gerne jeden Morgen zur Arbeit kommt. Das bedeutet nämlich, dass wir keine schlechte Laune haben und viel motivierter sind. Geht es uns gut, sind wir fröhlicher, aufgeschlossener und bereitwilliger für Neues und tun damit auch etwas Gutes für unsere Gesundheit. Die falsche Arbeit kann nämlich auch krank machen. Warum also nicht die Chance nutzen und Berufliches sowie Privates auf diese Art und Weise zu vereinen? Was gibt es Schöneres als glückliche, zufriedene Menschen, die nicht in jeden ihrer Tage lustlos hineinleben und schauen, was heute wohl so alles auf sie zukommen mag, sondern den Tag in die Hand nehmen und nicht den Zufall über ihr Leben regieren lassen!

Unser Leben heißt es. Also sollten wir auch etwas dafür tun, damit unser Leben läuft, wie es uns gefällt. Denn wenn wir es nicht selbst in den Händen halten, wer dann?

Testfoto @ Boris Gloger Consulting in Baden-Baden

Related posts:

  1. Bin ich am Arbeitsplatz zufrieden?
  2. Eine Erleuchtung: Scrum als Coaching-Tool!
  3. Komfort-, Stress- und Panikzone im Change Prozess

Categories: Blogs

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

Scrumology.com - Kane Mar - Fri, 09/26/2014 - 06:41

You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

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

  • How to Plan and Execute Programs without Shooting Agile in the Foot #agile #scrum
  • VIDEO: Based on AMAZON Top #10 Best Seller. FREE SCRUM BOOK here: #Scrum #Agile
  • Are you looking for Project Management Ideas ? Visit my blog in #pmp #pmi #scrum #agile
  • Jeff Sutherland & the Power of Scrum. Free talk in Atlanta. @jeffsutherland #Scrum #Agile #Versionone #HappyFamily
  • Check out “VersionOne Presents Jeff Sutherland, Co-Creator of Scrum for an Agile Community…” via @eventbrite
  • RT @stacywms: Check out “VersionOne Presents Jeff Sutherland, Co-Creator of Scrum for an Agile Community…” via @ev…
  • Repetitive Work in Math? That’s Good Great article about learning that even applies in the workplace.#Agile #Scrum
  • Developer II Keyword C#, .Net, JavaScript, OOAD… – #SanMarcos , TX (Get NET Jobs #NET #jobs #job #GetAllJobs
  • Should your entire #scrum team be co-located? I think so. Here’s 3 reasons why! #agile #pm #pmot
  • RT @AgileUniversity: Better User Stories. Certified Scrum Product Owner class Denver w/ @RonicaRoth #Scrum #Agile @R…
  • Organize your work with Podio #pmp #pmi #scrum #agile #podio @podio
  • The Scrum Guide, the ultimate definition of Scrum. #Scrum #Agile
  • A Practical Example On How To Use Agile And Scrum Tec http://t.co/NOgZkkZp66
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @FreeScrumEbook: VIDEO: Based on AMAZON Top #10 Best Seller. FREE SCRUM BOOK here: #Scrum #Agile
  • Scrum Mega Pack HARD COPY: #scrum #agile
  • Scrum Expert: Lean Agile South Africa, Cape Town & Johannesburg, South Africa, 6-10 October 2014 #agile #scrum
  • Scrum Expert: Agile Business Conference, London, UK, 8-9 October 2014 #agile #scrum
  • RT @yochum: Scrum Expert: Agile Business Conference, London, UK, 8-9 October 2014 #agile #scrum
  • RT @FreeScrumEbook: Scrum Mega Pack HARD COPY: #scrum #agile
  • RT @yochum: Scrum Expert: Lean Agile South Africa, Cape Town & Johannesburg, South Africa, 6-10 October 2014 #agile …
  • RT @yochum: Scrum Expert: Agile Business Conference, London, UK, 8-9 October 2014 #agile #scrum
  • #AGILE #SCRUM, Entrenamiento y Certificación Oficial #EXIN. Regístrate aquí: http://t.co/hrViPrA9FE
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Break down the silos between IT and the business – The Enterprisers Project #Agile #Scrum
  • Agile by McKnight, Scrum by Day is out! Stories via @heather_fox @rokazi
  • #Agile – Do you know how many tasks has to do an Scrum Master? – http://t.co/HsfFBXhohI
  • FREE SCRUM EBOOK as sold on Amazon: avail here. #Scrum #Agile inspired by #Ken Schwaber
  • RT @FreeScrumEbook: FREE SCRUM EBOOK as sold on Amazon: avail here. #Scrum #Agile inspired by #Ken Schwaber
  • The canonical definition of #Scrum has a new home:
    Good move @scrumalliance #unity #agile
  • Great example of #Agile #Scrum methods. Nordstrom Innovation Lab: Sunglass iPad App Case Study #video
  • RT @DanielRFeldman: Great example of #Agile #Scrum methods. Nordstrom Innovation Lab: Sunglass iPad App Case Study …
  • Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile inspired by #kschwaber
  • RT @FreeScrumEbook: Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile insp…
  • RT @FreeScrumEbook: Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile insp…
  • Agile Product Owner: Kanban for SAFe Teams #agile #scrum
  • RT @yochum: Agile Product Owner: Kanban for SAFe Teams #agile #scrum
  • Just came across on #Scrum. All 6 free vids in 75 minutes. #rails #rubyonrails #agile http://t.co/9LZEHOLtjy
  • The joy of timeboxed meetings #Scrum #Agile
  • The joy of timeboxed meetings #Scrum #Agile
  • RT @scrumology: The joy of timeboxed meetings #Scrum #Agile
  • Scrum Master / Agile Coach / Agile Project Manager – Reflex Computer Recruitment Ltd – Brighton Job Brighton
  • Categories: Blogs

    Kanban for SAFe Teams

    Agile Product Owner - Thu, 09/25/2014 - 20:16

    Hi Folks,

    I suspect many of you will be interested in this new guidance article which describes the application of Kanban for SAFe Agile Teams.  Here is the abstract to pique your interest.

    While not a software-specific method by original intent, the application of Kanban in software development can be quite useful. It provides a more granular view of the flow of work through the team, illustrates bottlenecks and delays to be addressed, and increases flow by application of work-in-process limits.  Properly used, Kanban provides a powerful set of constructs that every software enterprise should be able to apply in the scaled systems context. This article describes how Kanban can used by SAFe Teams in the content of their Agile Release Train.

    Thanks to Alex for this material contribution to SAFe, and given the fun we are all having with Agile method opinions in general, thanks also to all those whose comments we hope to receive on this post!

     

    Categories: Blogs

    Common Scrum Definition At Last!

    xProgramming.com - Thu, 09/25/2014 - 15:19

    I was asked to comment on this exciting press release:

    SCRUM ORGANIZATIONS ANNOUNCE OFFICIAL COLLABORATIVE ADOPTION OF SCRUM GUIDE

    And here’s the combined site.

    My comments:

    Strategically, the Scrum Alliance has been working toward there being a single agreed document among the “big three” Scrum organizations, Ken’s, Jeff’s, as the founders, and the Scrum Alliance, the largest organization formed in support of Scrum. (And originally formed by Ken / Jeff, one should certainly say.)

    The organizational split was brought about by the usual disagreements among people, not by any real disagreement about the ideas in and value of Scrum itself. It was, in my personal opinion, bad for everyone, even if it was inevitable given people’s differing goals.

    Carol McEwan, as new blood in the Scrum Alliance, felt the call to be unified more strongly than any historical call to schism. At her direction, when we wrote the original Core, we took care to agree with the Scrum Guide in any particular, because we were not trying to split — or further split — Scrum, but to produce a stable document that the Scrum Alliance could use as a reference and as a basis for its teaching and testing.

    Meanwhile, Carol reached out to people in Ken and Jeff’s circles, and with their help, to Ken and Jeff, and together they all hammered out an agreement to mutually own, mutually author, and mutually support the Scrum Guide. The Core team has known about this effort for months: we talked about it with Carol at the Scrum Gathering, and some of us, prior to that.

    I think it is fairly likely that the Core will remain as a sort of “study guide” for Scrum, as it contains some connecting material, like the references to the Agile Manifesto, and some specific material that supports Scrum Alliance training and testing. That’s just my guess, however. Of course, many authors will continue to write books and articles about Scrum.

    My personal view has long been that all these named ideas, Scrum, XP, Crystal, and even the related bodies of knowledge in Lean, Kanban, and so on, are close relatives, different philosophers’ view of the “same elephant”. Thus my Tumblr on that subject. I believe that we are not well served by treating these different views as being in competition, and that most of the differences are differences of understanding, differences based on individuals’ personal preferences, and differences of business goals. My own focus — to the extent that I can be said to have a focus — is in helping people see that these ideas belong together, that it is “all the same elephant”.

    So, anyway, this has been in development for at least months, years for some of us, and I’m quite pleased about it. I expect that the human differences will continue to plague us and I hope that we’ll continue to work on a broad and strong understanding of what we’re all about.

    My thanks go to Carol, for having the vision and the courage to push this through, and to all the principals for seeing the wisdom of the idea and helping this happen.

    Categories: Blogs