Skip to content

Feed aggregator

Feedback & NVC. Focus. #deliver

Mike Vizdos - Implementing Scrum - Mon, 02/09/2015 - 21:12

www.implementingscrum.com -- 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.

Still.

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

What’s New: More Flexibility with Custom Card Icons

Classify your work, your way, by using the Custom Icon field. Change the field label to reflect a category of work, and add custom card icons to quickly see the information. Class of Service, used to help further categorize the type work on a card (e.g., need to expedite, regulatory work, date dependent deliverable), is […]

The post What’s New: More Flexibility with Custom Card Icons appeared first on Blog | LeanKit.

Categories: Companies

A Product Backlog Prioritization Technique

Scrum Expert - Mon, 02/09/2015 - 17:11
The product backlog might be the more important item for a Scrum team as it represents the business value that the project should deliver to its customers. Putting a priority on the features and user stories is however not always easy for the product owners, especially if they are dealing with multiple stakeholders. In this article, Samantha Laing shares a technique that can help to improve the results of this activity. Author: Samantha Laing, Growing Agile, http://growingagile.co.za/ As a Product Owner do you ever feel that you have too much work and ...
Categories: Communities

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.

Range

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 http://rachelcdavies.github.io/
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

Chief Agile Officer?

Bobtuse Bobservations - Bob MacNeal - Fri, 02/06/2015 - 13:00
Does anyone need a Chief Agile Officer? Not is this galaxy. Imagine an old-school and a new-school narrative: 1. Old-School Imagine a storied company called Hammer & Sons. Some 20 years after...

Bobtuse can be wildly informative
Categories: Blogs

ThoughtWorks London Opening Party

thekua.com@work - Fri, 02/06/2015 - 12:05

Last night ThoughtWorks had a welcoming party to celebrate the opening of our new London office, located in the heart of Soho.

I didn’t take as many photos I would have liked, but it was a fun event with a couple of musicians: Emily Lee, Scott McMahon and an amazing set of food prepared by Ed Baines (chef of Randall and Aubin).

OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA
Categories: Blogs

Schweigen ist Gold – vom Wert des passiven Zuhörens

Scrum 4 You - Fri, 02/06/2015 - 08:45

Wie leicht fällt es Ihnen, in einem Gespräch – sei es mit nur einem Partner oder in Meetings – bewusst mal länger zu schweigen? Besonders dann, wenn Sie zur Sache jede Menge Wesentliches und Kompetentes beitragen könnten und diesen inneren Drang verspüren, sich einbringen zu wollen. Immer wieder fällt mir in Kommunikationstrainings oder im Coaching auf, dass vor allem Führungsverantwortliche eher auf das Reden als auf das (längere) Schweigen programmiert sind. Häufig stecken da natürlich durchaus legitime Bedürfnisse dahinter, wie andere zu informieren, zu motivieren, zu überzeugen, sich durchzusetzen usw. Trotzdem ist der Erfolg des gut gemeinten Redeschwalls meistens gering. Fast jeder kennt den Begriff des aktiven Zuhörens als eine fundamentale und seit langem favorisierte Methode für erfolgreiche und dialogorientierte Kommunikation – das ist schon mal ein Fortschritt. Aber in der Praxis wird diese Kenntnis oder Erkenntnis, dass aktives Zuhören durchaus weiterbringen könnte, zu selten umgesetzt. Gründe siehe oben.

Deshalb hier mein eindringliches Plädoyer für passives Zuhören. Im Gegensatz zum obigen Kommunikations-Oldie liegt hier der alleinige Schwerpunkt erst mal auf Schweigen und stiller Wahrnehmung.

Schweigen ist Wahrnehmung

Schweigen hat in fernöstlichen Praktiken wie Meditation, Yoga etc. einen sehr hohen Stellenwert, aber durchaus auch Traditionen in westlich-religiösen Bezügen (z.B. im kontemplativen Gebet). Man kann von zwei Anwendungsgebieten sprechen: Zum einen vom Schweigen mit sich selbst, alleine und zum anderen von einem situativen Element in der Kommunikation mit anderen Menschen. Beide stehen in einem engen Zusammenhang und profitieren voneinander. Schweigen mit sich selbst fördert die Selbstwahrnehmung. Es fokussiert auf das Selbst, dient der Entspannung und Entschleunigung. Gerade für Führungskräfte kann das eine wesentliche Kraftquelle für gute agile Führung sein.

Schweigen im Dialog, also passives Zuhören, schärft neben der situativen Selbstwahrnehmung (wo stehe ich im Moment? Was passiert gerade? Was kommt bei mir an? Wie geht es mir damit? Wie wirkt mein Partner auf mich? etc.) auch die so wichtige Fremdwahrnehmung. Es gibt dem anderen die Zeit sich einzubringen, sich Raum zu nehmen. Und das schafft u.a. die derzeit allseits gepriesene Augenhöhe. Es kann das Gegenüber indirekt und elegant aufwerten und bestätigen. Angemessenes Schweigen fördert Vertrauen und führt oft überraschenderweise zu Lösungen und Entwicklung. Das bedeutet, der Wert bezieht sich nicht nur auf die sozialen Bezüge, sondern durchaus auch auf die sachlichen und fachlichen Themen. Schweigen ist auch eine Intervention und löst mehr aus, als man gemeinhin denkt.

Im 1973 erschienenen Roman „Momo“ von Micheal Ende fasziniert folgende Stelle zu meinem Thema:
„Was die kleine Momo konnte wie kein anderer, das war das Zuhören. Das ist doch nichts Besonderes, wird nun vielleicht mancher Leser sagen, zuhören kann doch jeder. Aber das ist ein Irrtum. Wirklich zuhören können nur recht wenige Menschen. Und so wie Momo sich aufs Zuhören verstand, war es ganz und gar einmalig. Momo konnte so zuhören, dass dummen Leuten plötzlich sehr gescheite Gedanken kamen. Nicht etwa, weil sie etwas sagte oder fragte, was den anderen auf solche Gedanken brachte nein, sie saß nur da und hörte einfach zu, mit aller Aufmerksamkeit und aller Anteilnahme. Dabei schaute sie den anderen mit ihren großen, dunklen Augen an, und der Betreffende fühlte, wie in ihm plötzlich Gedanken auftauchten, von denen er nie geahnt hatte, dass sie in ihm steckten. Sie konnte so zuhören, dass ratlose, unentschlossene Leute auf einmal ganz genau wussten, was sie wollten. Oder dass Schüchterne sich plötzlich frei und mutig fühlten. Oder dass Unglückliche und Bedrückte zuversichtlich und froh wurden. Und wenn jemand meinte, sein Leben sei ganz verfehlt und bedeutungslos und er selbst nur irgendeiner unter Millionen, einer, auf den es überhaupt nicht ankommt, und er ebenso schnell ersetzt werden kann wie ein kaputter Topf und er ging hin und erzählte das alles der kleinen Momo, dann wurde ihm, noch während er redete, auf geheimnisvolle Weise klar, dass er sich gründlich irrte, dass es ihn, genauso wie er war, unter allen Menschen nur ein einziges Mal gab und dass er deshalb auf seine besondere Weise für die Welt wichtig war. So konnte Momo zuhören!”

Diese sicher etwas idealisierte Episode zeigt doch wunderbar den Kern meiner Botschaft auf. Schweigen und passives Zuhören hat einen hohen Wert dort, wo es im Dialog angemessen praktiziert wird. Der Kabarettist Dieter Nuhr hat den Satz geprägt: „Öfter mal die Schnauze halten.“ Kurz, prägnant und flapsig trifft diese Aussage durchaus das Thema.

In dem bemerkenswerten Buch „Embodied Communication“ (2013, Huber Verlag) schlagen Maja Storch und Wolfgang Tschacher das „AAO Geschenk“ der Kommunikation vor:

  • Aufmerksam sein (auf die Situation, auf die eigenen Affekte und die des Gegenübers),
  • Augen auf (Wechsel zwischen direktem Blickkontakt und peripherem Gesichtsfeld),
  • Ohren auf (zwei Ohren genügen, aber die wirklich offen).

Nicht verschwiegen werden soll hier natürlich, dass (intensives) Schweigen durchaus auch missverstanden werden kann, z.B. im Sinne von Ablenkung, Gleichgültigkeit, sogar Ignoranz, Hilflosigkeit oder Schwäche.

Meine Empfehlungen zu diesem Thema heißen also:

  • Mehr bewusstes Schweigen in der Kommunikation zulassen und einsetzen
  • Zuerst für sich allein üben (gar nicht so einfach), das Seine partiell loslassen oder vorerst sein lassen
  • AAO nutzen
  • Dem Dialogprozess mehr vertrauen
  • Erfahrungen mit passivem Zuhören sammeln und den eigenen, angemessenen Weg suchen und finden.

Agile Führung nimmt Meta-Perspektiven ein. Sie hält eine gesunde Distanz, gibt Raum, versucht differenziert wahrzunehmen und setzt funktionale Interventionen.

font-470589_1280

Categories: Blogs

Agile and Scrum training the Agile For All way

Agile For All - Bob Hartman - Fri, 02/06/2015 - 01:00

Take a moment to consider the last time you were in any sort of training environment. Were the tables set up “classroom style” so everyone faced forward in rows? Did the instructor read a lot of PowerPoint slides? Perhaps the room was even dark so everyone could see the PowerPoint better. Maybe you were lucky and you even had a workbook that was 500 pages long to go along with the training! <please feel free to gag at this point> Yes, we’ve all been there, and it’s horrible. It is one reason why many adults avoid any sort of educational opportunities – it’s just too horrible to ponder going through that again!

Well, people in our courses experience something completely different from what happens in a normal classroom. That didn’t happen by accident. We have spent a lot of time, money and effort over the past 5 years to become advanced practitioners of a training system from a book by Sharon Bowman known as Training From the Back of the Room (TFTBOTR). Between all of us, we’ve logged many hours in training with Sharon and picking her brain over the years. We’ve participated in many TFTBOTR seminars at conferences and even led sessions ourselves.

2013 Barry Staver, www.barrystaver.comRichard Lawrence and I (yes, in the picture to the left I am unfortunately, the height challenged one!) were privileged to spend one more incredible day with Sharon in January. After that day, both of us officially became “Certified Training From the Back of the Room Trainers” at the end of that day. This means we have progressed to a level where Sharon Bowman can confidently endorse us as trainers of her courses on the subject. We never really expected to get to this level, but after 5 years of using this in our daily work it was a natural fit. It was kind of nice to hear people in the course that day refer to us and say things like “it was great to see old hands like Richard and Bob show how easy this is!” That really made us happy to hear, because too often we don’t really know what we know because it has become so ingrained in us.

We often talk and write about our courses being different. They are highly experiential, involve more movement and interaction than most classes, don’t use much PowerPoint, etc., etc. We use these techniques because modern brain science makes it clear these things work better than anything else for helping people learn. Richard and I are both proud to be certified to teach these topics to others. And even though we may not host TFTBOTR trainings very often, the certification has given us more credibility. Believe it or not, there are companies that come close to hanging up on us when they hear how different our courses are from what they expected. Certification as TFTBOTR trainers lends additional credibility when talking about why we do the things we do.

If you haven’t taken a course with us, then we hope this article convinces you to consider it. Check our calendar of courses to see if any fit your schedule. We believe once you experience one of our courses you’ll change your mind about how adult education should be done!

Once you take a course with us you’ll be eligible to come to our 2015 Humanizing Work Conference where we take what happens in the classroom and amp it up. WAY UP! Check out the video on our conference homepage at www.humanizingwork.com for a taste of what you missed if you didn’t attend in 2014. We hope to see you in one of our classes soon, and at our Humanizing Work conference in the Park Hyatt Resort and Spa in the beautiful mountain town of Beaver Creek, Colorado this July. Learning can actually be fun. Try one of our courses and find out how! Just to show you how fun, just last week I got this evaluation form after a class (it made my day):eval1

The post Agile and Scrum training the Agile For All way appeared first on Agile For All.

Categories: Blogs

Clean Tests: Building Test Types

Jimmy Bogard - Thu, 02/05/2015 - 23:38

Posts in this series:

In the primer, I described two types of tests I generally run into in my systems:

  • Arrange/act/assert fully encapsulated in a single method
  • Arrange/act in one place, assertions in each method

Effectively, I build tests in a procedural mode or in a context/specification mode. In xUnit Test Patterns language, I’m building execution plans around:

There’s another pattern listed there, “Testcase Class per Feature”, but I’ve found it to be a version of one of these two – AAA in a single method, or split out.

Most test frameworks have some extension point for you to be able to accomplish both of these patterns. Unfortunately, none of them are very flexible. In my tests, I want to have complete control over lifecycle, as my tests become more complicated to set up. My ideal would be to author tests as I do everything else:

  • Method arguments for variation in a single isolated test
  • Constructor arguments for delivering fixtures for multiple tests

Since I’m using Fixie, I can teach Fixie how to recognize these two types of tests and build individual test plans for both kinds. We could be silly and cheat with things like attributes, but I think we can be smarter, right? Looking at our two test types, we have two kinds of test classes:

  • No-arg constructor, methods have arguments for context/fixtures
  • Constructor with arguments, methods have no arguments (shared fixture)

With Fixie, I can easily distinguish between the two kinds of tests. I could do other things, like key off of namespaces (put all fast tests in one folder, slow tests in another), or separate by assemblies, it’s all up to me.

But what should supply my fixtures? With most other test frameworks, the fixtures need to be plain – class with a no-arg constructor or similar. I don’t want that. I want to use a library in which I can control and build out my fixtures in a deterministic, flexible manner.

Enter AutoFixture!

I’ll teach Fixie how to run my tests, and I’ll teach AutoFixture how to build out those constructor arguments. AutoFixture is my “Arrange”, my code is the Act, and for assertions, I’ll use Shoudly (this one I don’t care as much about, just should-based is enough).

First, let’s look at the simple kinds of tests – ones where the test is completely encapsulated in a single method.

Testcase Class per Class

For TestClass Per Class, my Fixie convention is:

public class TestcaseClassPerClassConvention : Convention
{
    public TestcaseClassPerClassConvention()
    {
        Classes
            .NameEndsWith("Tests")
            .Where(t => 
                t.GetConstructors()
                .All(ci => ci.GetParameters().Length == 0)
            );

        Methods.Where(mi => mi.IsPublic && mi.IsVoid());

        Parameters.Add(FillFromFixture);
    }

    private IEnumerable<object[]> FillFromFixture(MethodInfo method)
    {
        var fixture = new Fixture();

        yield return GetParameterData(method.GetParameters(), fixture);
    }

    private object[] GetParameterData(ParameterInfo[] parameters, Fixture fixture)
    {
        return parameters
            .Select(p => new SpecimenContext(fixture).Resolve(p.ParameterType))
            .ToArray();
    }
}

First, I need to tell Fixie what to look for in terms of test classes. I could have gone a lot of routes here like existing test frameworks “Things with a class attribute” or “Things with methods that have an attribute” or a base class or a namespace. To keep things simple, I look for classes named “Tests”. Next, because I want to target a workflow where AAA is in a single method, I make sure that this class has only no-arg constructors.

For test methods, that’s a bit easy – I just want public void methods. No attributes.

Finally, I want to fill parameters from AutoFixture. I tell Fixie to add parameters from AutoFixture, resolving each parameter value one at a time from AutoFixture.

For now, I’ll leave the AutoFixture configuration alone, but we’ll soon be layering on more behaviors as we go.

With this in place, my test becomes:

public class CalculatorTests
{
    public void ShouldAdd(Calculator calculator)
    {
        calculator.Add(2, 3).ShouldBe(5);
    }

    public void ShouldSubtract(Calculator calculator)
    {
        calculator.Subtract(5, 3).ShouldBe(2);
    }
}

So far so good! Now let’s look at our Testcase Class per Fixture example.

Testcase Class per Fixture

When we want to have a single arrange/act, but multiple assertions, our test lifecycle changes. We now want to not have to re-run the Arrange/Act every single time, we only want it run once and then each Assert work off of the results of the Act. This means that with our test class, we want it only run/instantiated once, and then the asserts happen. This is different than parameterized test methods, where we want the fixture recreated with every test.

Our Fixie configuration changes slightly:

public class TestcaseClassPerFixtureConvention : Convention
{
    public TestcaseClassPerFixtureConvention()
    {
        Classes
            .NameEndsWith("Tests")
            .Where(t => 
                t.GetConstructors().Count() == 1
                && t.GetConstructors().Count(ci => ci.GetParameters().Length > 0) == 1
            );

        Methods.Where(mi => mi.IsPublic && mi.IsVoid());

        ClassExecution
            .CreateInstancePerClass()
            .UsingFactory(CreateFromFixture);
    }

    private object CreateFromFixture(Type type)
    {
        var fixture = new Fixture();

        return new SpecimenContext(fixture).Resolve(type);
    }
}

With Fixie, I can create as many configurations as I like for different kinds of tests. Fixie layers them on each other, and I can customize styles appropriately. If I’m migrating from an existing testing platform, I could even configure Fixie to run the existing attribute-based tests!

In the configuration above, I’m looking for test classes ending with “Tests”, but also having a single constructor that has arguments. I don’t know what to do with classes with multiple constructors, so I’ll just ignore those for now.

The test methods I’m looking for are the same – except now I’ll not configure any method parameters. It would be weird to combine constructor arguments with method parameters for this style of test, so I’m ignoring that for now.

Finally, I configure test execution to create a single instance per class, using AutoFixture as my test case factory. This is the piece that starts to separate Fixie from other frameworks – you can completely customize how you want your tests to run and execute. Opinionated frameworks are great – but if I disagree, I’m left to migrate tests. Not a fun proposition.

A test that uses this convention becomes:

public class InvoiceApprovalTests
{
    private readonly Invoice _invoice;

    public InvoiceApprovalTests(Invoice invoice)
    {
        _invoice = invoice;

        _invoice.Approve();
    }

    public void ShouldMarkInvoiceApproved()
    {
        _invoice.IsApproved.ShouldBe(true);
    }

    public void ShouldMarkInvoiceLocked()
    {
        _invoice.IsLocked.ShouldBe(true);
    }
}

The constructor is invoked by AutoFixture, filling in the parameters as needed. The Act, inside the constructor, is executed once. Finally, I make individual assertions on the result of the Act.

With this style, I can build up a context and incrementally add behavior via assertions. This is a fantastic approach for lightweight BDD, since I’m focusing on behaviors and adding them one at a time.

Next up, we’ll look at going one step further and integrating the database into our tests and using Fixie to wrap interesting behaviors around them.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Making Agile Product Roadmaps Work

Scrum Expert - Thu, 02/05/2015 - 19:01
A product roadmap is a high-level plan that shows how a product is likely to grow over time. This creates a continuity of purpose, aligns stakeholders and facilitates prioritisation. Unfortunately, many product owners and teams struggle with their product roadmaps. The roadmaps are often dominated by features, and the features are sometimes regarded as a commitment by senior management. This talk shares some insights on leveraging agile roadmaps successfully. It introduces a new goal-oriented, agile product roadmap, which combines shared goals and key features into a strategic plan, and provides an ...
Categories: Communities