Skip to content

Feed aggregator

Laloux Culture Model

Agilitrix - Michael Sahota - Thu, 01/29/2015 - 21:33

Looking for a way to help evolve your organization’s culture? Frederic Laloux’s model provides a clear picture of how culture may evolve in an organization.

The model comes from Reinventing Organizations – a landmark book in the development of organizations that unleash the talents of people to get astonishing results. The book is grounded in case studies from around the world of organizations that are succeeding in a new way of working. The book has inspired me and helped me see much more clearly what is possible for myself and the clients I work with.

Laloux Culture Model

Frederic has a really awesome model for understanding organizational culture. It looks like this:

It shows how our society (over thousands of years) has evolved new ways of working together. Each stage has value: more advanced is not necessarily better – it’s about fit for context. It is derived from other models such as Integral, Spiral Dynamics, etc. Note that Laloux does not call this a culture model – he refers to it as stages in evolution of consciousness and organization.

Centralized Power & Structure [Red & Amber]

Red is about power: I am the leader – do what I say or else. Key innovations are the division of labour and authority. Examples include street gangs or tribal militias.

Amber organizations channel power through a hierarchy with formal roles and reporting lines (command & control). They establish stable processed that allow them to scale to a large size. Current examples are: military, government agencies, public school systems.

Achievement [Orange]

Orange is about a shift to focus on achievement: bigger and better. Innovation is key: how do we evolve our process? What projects do we need to improve things? With orange, we create plans and hold people accountable for results (predict & control). Since the focus is now on results, a meritocracy is formed based on who actually delivers. The organization is seen as machine to be exploited. Examples are multinational organizations and charter schools.

People [Green]

Green organizations focus on the empowerment of workers (within the hierarchy) as the key for driving success. There are explicit shared values that guide behaviour and decision-making. Green organizations have family as a guiding metaphor. They also have a clear purpose to support coherent activity. Green organizations see a bigger picture beyond profits: workers, customers and their role in the community. Examples include Southwest Airlines, Zappos, Ben & Jerry’s.

Shared Power [Teal]

Teal organizations are decentralized into autonomous teams or groups. Power is shared and people are self-managing. Decisions are made independently – there is no centralized group telling people what to do. Decision-making independence is enhanced with visibility and advice. Trust replaces process. People’s whole selves (mind, body, heart, spirit) are welcomed. The organization evolves through an emergent process since everyone can make decisions. The metaphor for Teal is that of a living system. Examples include: Patagonia, Morning Star,… (more in the book).

Go Read The Book

Creating Organizations Guided by the next stage of human evlolutionThis is the best book I have read in years. It has helped me tremendously in getting a deeper understanding of the work I have been doing with culture for the last few years and helped me see the larger pattern of organizational evolution much more clearly.

In upcoming posts, I will write more about how to use this model and the Teal stage.

 

 

 

 

 

The post Laloux Culture Model appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Whole Agile – Unleash People & Organizations Agile is incomplete. We need to augment it to create...
  2. Letting Go of Agile (Culture) “If you want something very, very badly, let it go...
  3. VAST – Virtuous Cycle for Connection It’s all about how we show up. If we show...

YARPP powered by AdBistroPowered by

Categories: Blogs

Clean Tests: A Primer

Jimmy Bogard - Thu, 01/29/2015 - 16:25

Posts in this series:

Over the course of my career, I’ve an opportunity to work with a number of long lived codebases. Ones that I’ve been a part of since commit one and continue on for six or seven years. Over that time, I’ll see how my opinions on writing tests have changed throughout the years. It’s gone from mid 2000s mock-heavy TDD, to story-driven BDD (I even wrote an ill-advised framework, NBehave), to context/spec BDD. I looked at more exotic testing frameworks, such as MSpec and NSpec.

One advantage I see in working with codebases for many years is that certain truths start to arise that normally you wouldn’t catch if you only work with a codebase for a few months. And one of the biggest truths to arise is that simple beats clever. Looking at my tests, especially in long-lived codebases, the ability for me to understand behavior in a test quickly and easily is the most important aspect of my tests.

Unfortunately, this has meant that for most of the projects I’ve worked with, I’ve had to fight against testing frameworks more than work with them. Convoluted test hierarchies, insufficient extensibility, breaking changes and pipelines are some of the problems I’ve had to deal with over the years.

That is, until an enterprising coworker Patrick Lioi started authoring a testing framework that (inadvertently) addressed all of my concerns and frustrations with testing frameworks.

In short, I wanted a testing framework that:

  • Was low, low ceremony
  • Allowed me to work with different styles of tests
  • Favored composition over inheritance
  • Actually looked like code I was writing in production
  • Allowed me to control lifecycle, soup to nuts

Testing frameworks are opinionated, but normally not in a good way. I wanted to work with a testing framework whose opinions were that it should be up to you to decide what good tests are. Because what I’ve found is that testing frameworks don’t keep up with my opinions, nor are they flexible in the vectors in which my opinions change.

That’s why for every project I’ve been on in the last 18 months or so, I’ve used Fixie as my test framework of choice. I want tests as clean as this:

using Should;

public class CalculatorTests
{
    public void ShouldAdd()
    {
        var calculator = new Calculator();
        calculator.Add(2, 3).ShouldEqual(5);
    }

    public void ShouldSubtract()
    {
        var calculator = new Calculator();
        calculator.Subtract(5, 3).ShouldEqual(2);
    }
}

I don’t want gimmicks, I don’t want clever, I want code that actually matches what I do. I don’t want inheritance, I don’t want restrictions on fixtures, I want to code my test how I code everything else. I want to build different rules based on different test organization patterns:

public class ApproveInvoiceTests {
    private Invoice _invoice;
    private CommandResult _result;
    
    public ApproveInvoiceTests(TestContext context) {
        var invoice = new Invoice("John Doe", 30m);
        
        context.Save(invoice);
        
        var message = new ApproveInvoice(invoice.Id);
        
        _result = context.Send(message);
        
        _invoice = context.Reload(invoice);
    }
    
    public void ShouldApproveInvoice() {
        _invoice.Status.ShouldEqual(InvoiceStatus.Approved);
    }
    
    public void ShouldRaiseApprovedEvent() {
        _result.Events.OfType<InvoiceApproved>().Count().ShouldEqual(1);
    }
}

Fixie gives me this, while none others can completely match its flexibility. Fixie’s philosophy is that assertions shouldn’t be a part of your test framework. Executing tests is what a test framework should provide out of the box, but test discovery, pipelines and customization should be completely up to you.

In the next few posts, I’ll detail how I like to use Fixie to build clean tests, where I’ve stopped fighting the framework and I take control of my tests.

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

Categories: Blogs

What Development & Test Managers do in Agile Organizations

Johanna Rothman - Thu, 01/29/2015 - 15:28

Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.

If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:

  • Develop trusting relationships with the people on the project team, and in their function.
  • Provide coaching and mentoring opportunities for people.
  • Provide communities of practice for the people.
  • Remove obstacles for the people and team.
  • Start and nurture the hiring effort whenever you need to hire new people.
  • Help people with career development.
  • Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
  • Provide coaching and meta-coaching when people want it.
  • Help the organization understand its capacity and make decisions about the project portfolio.
  • Help influence the rest of the organization with the agile culture.

Functional managers are champions for the team, and shepherds for the process. They are servant leaders.

Here’s what functional managers do not do:

  • Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other.
  • Move people on or off teams, once you or the team establishes itself.
  • Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
  • Micromanage any part of the project work. Or, manage any part of the project work.

What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.

Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.

If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.

Categories: Blogs

How It Works: User Stories

Rally Agile Blog - Thu, 01/29/2015 - 15:00

Next Tuesday, February 10, our TeamStart webinar series will answer your questions about "Writing Great User Stories." Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give some good Q+A. We’re going to talk about writing compelling stories that focus on business value. Here are a few questions from past "User Stories" webinars:

  • What are some tips for writing a great user story?
  • When do I break down user stories?
  • Who should drive the definition of acceptance criteria?

Here's a preview of what you'll learn in the TeanStart webinar.

Tips for Writing a Great User Story

A great user story has three areas of focus: Who, What, and Why. A great user story is also written from the perspective of the user (hence the name); and a great user story "tells a story" about what that user wants to be able to do, and why (for what outcome.)

Who: Define the person who receives value from a new user story. For example:

As a user of the website ...
As an internal team member ...
 

What: Indicate what needs to be delivered, from the perspective of the user. For example:

... I want to purchase my items with a credit card ...
... I need a new testing infrastructure ...
 

Why: Show the value the user gains from the story:

... so that I have a convenient and secure way to pay electronically.
... so that I can prepare for the new test requirements of our organization.

When to Break Down User Stories

When the estimated size of a user story exceeds the total velocity available in a team’s iteration, the story cannot fit and must be broken down into smaller stories. User stories can be broken down multiple times as they move up the backlog -- transitioning from a large, loosely-defined, parent story into a set of small, defined, child user stories that make progress towards the overall goal.

Who Should Drive the Definition of Acceptance Criteria

The entire development team assists the product owner in creating acceptance criteria. Product owners represent the business and stakeholders, and communicate the needs of a story to the team. Teams communicate with the product owner about what implementation methods are possible, and how a story may be completed to meet business needs.  


What are your questions? Get them answered. Join the TeamStart webinar series on Tuesday, February 10th, to learn about "Writing Great User Stories."

Rob Ward
Categories: Companies

Optional Conference, Budapest, Hungary, March 24-25 2015

Scrum Expert - Thu, 01/29/2015 - 11:28
The Optional Conference is a two-day event focused on Agile software development and Agile management that take place in Budapest, Hungary. It features local and international Agile and Scrum experts that engage the audience in presentations and workshops. In the agenda of the Optional Conference, you can find topics like “Waste is Optional”, “Case study: winning a tender with Story Mapping”, “Finding the right practice for the various levels of planning”, “Keeping Governance and Audit Agile”, “Radical Management”, “The Scaling Dilemma”, “Agile Teams: Self-Organizing, Collocated, and Distributed”, “Agile Architecture – How ...
Categories: Communities

8 Rituals of Amazing Scrum Masters

Illustrated Agile - Len Lagestee - Thu, 01/29/2015 - 01:00

Having worked with many Scrum Masters, I am beginning to recognize patterns and behaviors of some of the best. It appears to me that the Scrum Masters having the most impact with their teams and throughout the organization establish strong rituals for themselves. These rituals provide the momentum to overcome the challenges and busyness of […]

The post 8 Rituals of Amazing Scrum Masters appeared first on Illustrated Agile.

Categories: Blogs

SonarQube 5.0 in Screenshots

Sonar - Wed, 01/28/2015 - 17:56

The team is proud to announce the release of SonarQube 5.0, which includes many new features

  • Issues page redesign
  • Keyboard shortcuts added to Issues
  • Built-in SCM support

Issues page redesign

With this version of the SonarQube platform, the Issues page has had a complete overhaul.

Issues are grouped in the list by file, and from the list of issues, you can easily navigate to the issue in the context of the code, as you’re used to seeing it,

Issue search has also been overhauled. You can still choose from criteria, but now next to each facet of the criteria, you see a count of the relevant issues.

Selected facets are highlighted in blue, and selecting/deselecting a facet immediately (okay, there’s a quick trip to the server and back) updates your search results and the issue counts next to all the other facets.

Keyboard shortcuts added to Issues

The intent behind the redesign is to allow you to use the Issues page quickly and efficiently to manage issues on a daily basis. To that end, extensive effort has gone into providing a broad set of keyboard short cuts. ‘?’ brings up the list, and Esc closes it.

From the list of issues, right-arrow takes you to the issue-in-context, and left-arrow takes you back to the list. In either context, up-arrow/down-arrow takes you to the next issue – in the same file or the next one – and you can use the shortcuts to comment, assign…

Built-in SCM support

SCM “blame” information has been an important data point in the SonarQube interface for a long time, but until now a plugin was required to use it. Now SCM data comes as part of the platform, with built-in support for SVN and Git.

Speaking of Git, its rise in popularity has meant that the use of ‘/’ in branch names has become increasingly common. Until now, that was unsupported by SonarQube. That changes with 5.0, presumably making many Git-ers happy. :-)

That’s all, Folks!

Time now to download the new version and try it out. But don’t forget that you’ll need Java 7 to run this version of the platform (you can still analyse Java 6 code), and don’t forget to read the installation or upgrade guide.

Categories: Open Source

30 seconds and 5 lines of code later

Derick Bailey - new ThoughtStream - Wed, 01/28/2015 - 13:00

I was about to pull my hair out.

I had been looking at my monitor for nearly an hour, trying to wrap my head around the inverse tree traversal that I had to do. Start at the bottom, work my way up, find my way back to where I started and update each node along the way. It didn’t sound too hard… why was I having such a difficult time envisioning the code?
talk-to-someone

After exclaiming to my friend Cory that my brain was about to explode, I dove in to a very high level description of the problem. When a parent node goes in to an error state, I have to mark all the children as unresolvable… but I’m looking at an array of items where each item knows about it’s parents.

30 seconds in to the conversation, Cory asked me a question.

5 lines of code later, I had a working solution and it was brilliant!

Perspective

The truth is that I already had everything I needed – everything, except for the right perspective on the problem. I wasn’t looking at things from the right angle.

I had this preconceived notion that I had to start from the bottom of the tree structure I was dealing with. All Cory did was ask me if I knew which node was going in to an error state, at the moment it went in to error. Yes, of course I did – I was marking it as error. So, can’t I just travel down from there? Well, no… I … have already pre-computed the child nodes in a previous iteration! YES! I can travel down the tree from there!

It’s a problem that we often face in many different contexts. We have an idea that guides us toward a solution to a problem, and we get fixated on that idea. Or we have a problem that seems to twist itself in circles with no way out. But the moment we explain the situation to someone else, the solution suddenly becomes obvious.

That subtle shift in perspective when we have to explain a few extra details, when that person asks an “obvious” question, or when we just say the words out loud and they suddenly don’t make sense… forcing yourself to turn your implicit knowledge of a situation in to an explicit statement can be a very powerful thing, indeed.

Let The Anti-Social Be Social (Occasionally)

I’m not a people person, quite honestly. I don’t always want to be alone, but I rarely want to be the center of attention or in a big crowd. I’m definitely on the shy scale, and the awkward side of things in real life. I put on a good show, sometimes, but not always.

When I talk about the importance of talking, then, it shouldn’t be taken lightly.

This is advice that comes from years of experience in sitting around, pulling my hair out, trying to solve something and having the solution become perfectly obvious the moment I begin talking about it. This is such a regular occurrence for me, that I can’t imagine not having someone to talk to on a regular basis. It doesn’t have to be every day (and frankly, I don’t want it to be every day). But a couple of days a week, for me, is critical.

I Need That Conversation

That one conversation, that small spark of perspective change, that moment of being forced to explain something in new terms… that’s the reason I go in to my client’s office twice a week, and the reason Cory and I go to a coffee shop every Wednesday.

Don’t underestimate the value of other people’s perspectives… or the value of you being willing to listen to someone else and ask “obvious” questions. You may find yourself on the giving end of that spark of genius, if you only let yourself be available.

– Derick

Categories: Blogs

Zeit für eine neue Meeting-Kultur

Scrum 4 You - Wed, 01/28/2015 - 08:27

Meetings haben ihren guten Ruf verloren. Vorbei die Zeiten, in denen ein gut gefüllter Terminkalender Indikator für Produktivität war. Heute sind Meetings gleichbedeutend mit langweiligen Diskussionsrunden, in denen alles getroffen wird – außer Entscheidungen. Dabei sind Meetings im Grunde völlig in Ordnung – seit Urzeiten kommen Menschen in Familie, Gesellschaft und Wirtschaft zusammen, wenn es darum geht, die wichtigen Dinge im Leben zu besprechen. Es wird immer irgendeine Form von Meetings geben – die Frage ist nur, wie diese sinnvoll gelebt werden können. Hier ein paar Tipps & Tricks für eine neue Meeting-Kultur.

Alle Hände voll zu tun

Oft sind Meetings wie gute Vorsätze für das neue Jahr: Es ist leicht, sie zu fassen, aber verdammt schwer, sie konsequent umzusetzen. Deshalb ist unbedingt darauf zu achten, dass alle Meetings mit einem klaren Nutzen ausgehen, indem am Ende Maßnahmen, Vereinbarungen, Commitments konkretisiert werden. Mehr noch: Anstatt die Maßnahmen bloß zu benennen, warum diese nicht gleich umsetzen?

Tipp: Sobald in einem Meeting klar wird, dass etwas Konkretes zu tun ist – jemand muss hinzugezogen, eine Information eingeholt werden – handeln Sie sofort. Rufen Sie die Person noch während des Meetings an (bitte mit Freisprechfunktion, damit alle teilnehmen können), lassen Sie die Information vor aller Augen recherchieren, legen Sie Prototypen und Wireframes zur sofortigen Begutachtung aus. Wählen Sie einen Raum, der nicht mit Tischen und Stühlen zugestellt ist, so dass die Teilnehmer frei interagieren können. Sie werden sehen, wie das die Teilnehmer vom Raum der Möglichkeiten in den Raum der Handlungen bringt. So wird die Unterscheidung zwischen Meeting und der eigentlichen Arbeit immer irrelevanter.

Unrentable Meetings abschaffen

Wer ein Meeting einberuft, raubt den Teilnehmern Arbeits- und Lebenszeit. Das sollte nie leichtfertig geschehen und in jedem Fall gut begründet sein. Am Ende jedes Meetings ist zu überprüfen, ob die Zeit sinnvoll investiert wurde. Und ein Meeting sollte grundsätzlich nie länger als 90 Minuten dauern – es gibt genügend Studien, die zeigen, dass danach die Aufmerksamkeit der Teilnehmer den Bach hinuntergeht.

Tipp: Bitten Sie die Teilnehmer darum, vor Verlassen des Meetings ihren Return on Time Invested zu visualisieren. Zeichnen Sie dafür eine Skala von 0 (= kein Return on Time Invested) bis 5 (= sehr hoher Return on Time Invested) auf einem Flipchart und hängen Sie diese neben den Ausgang. Drücken Sie jedem Teilnehmer ein Post-It oder ein Voting Dot in die Hand, und bitte Sie die Teilnehmer, damit einen Punkt auf der Skala zu markieren. Nutzen Sie das Feedback, um sich beim nächsten Mal zu überlegen, ob das Meeting in dieser Form wirklich nötig ist.

Zeitfetischismus zahlt sich aus

Wenn ich ein Meeting für eine Stunde anberaume, dann prüfe ich nach spätestens 30 Minuten, ob wir es beenden können. Häufig ist das der Fall, denn bei einer klar definierten Agenda und Vorbereitung der Teilnehmer entsteht ein guter Kommunikationsfluss, der sich nur an wenigen, kritischen Stellen aufhält. Verharrt das Meeting hingegen in langwierigen Argumentationsrunden ohne Entscheidungen, dann wird auch die ursprünglich anberaumte Zeit nicht ausreichen – eine Unterbrechung ist dann erst recht sinnvoll, um zu einem späteren Zeitpunkt in anderer Konstellation wieder zusammenzukommen.

Tipp: Fragen Sie zur Halbzeit eines Meetings (also nach 30 Minuten bei einem einstündigen Meeting), ob eine Verlängerung erforderlich ist. Wenn ja, verlängern Sie das Meeting um die Hälfte der bereits abgelaufenen Zeit (in diesem Fall um 15 Minuten). Fragen Sie nach Ablauf dieser Zeit erneut, ob eine Verlängerung erforderlich ist. Falls ja, verlängern Sie noch einmal, teilen Sie dabei aber die verlängerte Zeit wiederum um die Hälfte (hier um 7.5 Minuten). Und so weiter. Sie werden sehen, wie die Teilnehmer von Meeting zu Meeting immer zeitbewusster werden und genau abwägen, ob eine Verlängerung erforderlich ist.

Freiwilligkeit – mit allen Konsequenzen

Menschen, die fragen, ob sie an dem Meeting teilnehmen müssen, haben meist Besseres zu tun. Es ist für mich eine Frage des Respekts, andere zu Meetings tatsächlich einzuladen (und nicht mit Pflichtfeldern einzuberufen). In jedem Meeting sollte daher das Gesetz der zwei Füße gelten:

“Wenn Sie in einer Gruppe nichts mehr lernen oder beitragen können, dann dürfen Sie gehen. Ehren Sie die Gruppe durch ihre Ehrlichkeit und suchen Sie sich neue Aufgaben, denn Sie bestimmen alleine wo, wie und wie lange Sie sich beteiligen. Lassen Sie sich von Ihren Füßen leiten. Gehen Sie dahin, wo Sie Ihre Energie und Aufmerksamkeit einbringen wollen, nur dort werden Sie produktiv sein. Dies ist ein Gesetz: Es ist mehr als nur erlaubt, es ist vorgeschrieben.” (Harrison Owen – User’s Guide to Open Space Technology)

Tipp: Machen Sie Ihrem Mitarbeitern klar, dass ab sofort kein Meeting mehr verpflichtend besucht werden muss. Denn es ist die Verantwortung jedes einzelnen zu entscheiden, wie die eigene Zeit am produktivsten einzusetzen ist. Machen Sie aber auch klar, dass die Entscheidungen der Anwesenden von den Nichtanwesenden mitzutragen sind.

Es ist Zeit, Meetings wieder produktiv und spannend zu machen. Die hier genannten Tipps sind leichter umzusetzen, als Sie vielleicht denken. Allerdings lohnt es sich, dafür eine dedizierte Rolle – die des Moderators – einzusetzen. Dieser sollte durchaus Ahnung von der Materie haben und in der Lage sein, die Diskussion etwa um gute Fragen zu bereichern. Vor allem aber sollte er oder sie in der Lage sein, Meetings so zu führen, dass Entscheidungen getroffen und am besten gleich umgesetzt werden können.

fuesse

Categories: Blogs

Blue Agility Partners With Rally on Scaled Agile Adoption

Scrum Expert - Tue, 01/27/2015 - 23:11
Blue Agility has announced a partnership with Rally. This cooperation aims to team the market-leading strengths of each company in helping enterprise-level organizations adopt and scale Agile software development initiatives in an efficient and successful manner. Together, Blue Agility and Rally will address the challenges inherent in scaling Agile to larger, enterprise-wide implementations. This includes enabling the creation, management and execution of development plans, providing the capabilities for the capture and transfer of knowledge, implementing best practices and processes, strengthening existing training and coaching services, and achieving long-term sustainability. This partnership ...
Categories: Communities

VersionOne Announces Winter Release

Scrum Expert - Tue, 01/27/2015 - 23:00
VersionOne has announced its 2015 Winter Release, which includes Strategic Themes aligned with SAFE, Epic Timeline Drilldown, Forecasting with Monte Carlo Simulation, and more. These new capabilities make scaling agile initiatives easier by enabling project and portfolio managers to view, prioritize, forecast and align projects from the highest business initiatives to execution. The new VersionOne capabilities improve business alignment and agility to adapt to evolving plans and priorities: * Strategic Themes: Ability to group and view all items that fall within a particular strategic theme, enabling product owners to easily prioritize and ...
Categories: Communities

Protected: RCI Testing Blog Post

Leading Agile - Mike Cottmeyer - Tue, 01/27/2015 - 21:28

This content is password protected. To view it please enter your password below:

Password:

The post Protected: RCI Testing Blog Post appeared first on LeadingAgile.

Categories: Blogs

Putting the BA into BAcklog

Scrum Expert - Tue, 01/27/2015 - 20:52
Business Analysis (BA) is a growing profession which is helping organisations to manage business transformation in an ever changing and complex world. Business analysts work across the business change lifecycle; they develop early understanding of business needs so that the right projects are funded for the right reasons and ensure that the solutions are developed that meet these needs. As a result, the Agile philosophy and techniques are fundamental to business analyst’s work. This presentation shares some experience of being an agile BA in the public sector and how applying Agile ...
Categories: Communities

Best Practices for Continuous Integration and Deployment on AWS

TV Agile - Tue, 01/27/2015 - 20:02
With AWS, companies now have the ability to develop and run their applications with speed and flexibility like never before. Working with an infrastructure that can be 100 percent API driven enables businesses to use lean methodologies and realize these benefits. This in turn leads to greater success for those who make use of these […]
Categories: Blogs

What’s in a Voice? Communicating Who You Are [Updated with edits]

Learn more about our Scrum and Agile training sessions on WorldMindware.com

In our professional lives and in doing business, we commonly follow the advice to “dress for success.” We make certain to wear that business suit, or a particular pair of snazzy heels, or a certain color of tie. For better or for worse, we can be judged in the first few seconds of contact with a potential employer or customer by our attire, our hairstyle, our facial expression, our nose ring…

A more subtle way we evaluate a person is through the sound of his or her voice. The voice is a very personal instrument, and it can communicate so much about who you are, your abilities and your intentions.

The voice can tell you whether someone is nervous or at ease. Whether they’re authentic or stringing you a line. Whether they care if they communicate with you or not. When I was a kid, I thought I could detect when someone was lying to me by a certain glitch in the voice, or a tell-tale tone. Often, our brain makes intuitive judgements about what’s being said to us, and is sensitive to vocal rhythm, clarity, tones, and the use of language.

One may think it’s not fair to judge someone by their voice. Let’s face it, a voice – like being short, or having a large nose – is usually unchangeable. But it’s how the voice is used that matters. We all have an inherently full, expressive voice, but things happen to us in life that can negatively influence and/ or harm that voice.

Think of the person who speaks so quietly it’s almost a whisper – you must lean closer to catch what she says. This person may have had some trauma in her life, like being constantly told as a child to ‘be quiet’, to de-voice her. I know people whose greatest fear is public speaking, who quake inwardly and outwardly, even if they have something important to share with others.

Personality is also expressed through the voice. Imagine the annoyingly loud talker sitting nearby in a restaurant. This is certainly someone who wants too much attention and tries to get it by being overbearing. Or the fast-talker, who doesn’t want any other opinions but his own to be expressed, and doesn’t give the listener an opportunity to think or to respond, lest they disagree with him.

Anyone can be trained to use their voice for positive communication. A voice is an instrument that can become effective and optimal with practice.

Here’s a few things to think about in how you use your voice:

  • Are you clearly enunciating your words so as not to be mis-heard?

  • Are you directing your voice to the person or people you want to communicate with?

  • Are you speaking in a rhythm that’s neither too fast nor too slow?

  • Are you allowing your true feelings or intentions to come through?

  • Are you being honest?

The voice is just one of the important tools we use to communicate. If your work requires relating to other people in any way, for example, making presentations, or promoting a product, consider how you use your voice and what it may communicate about you!

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

The Value of Planning Together

Agile For All - Bob Hartman - Tue, 01/27/2015 - 16:15
Yes! I love hearing great stories like this from our clients and students!

Yes! I love hearing great stories like this from our clients and students!

If you’ve taken part in any of our Scrum classes, then you know we highly value the power of face-to-face communication. The emergent power of real-time collaboration allows us to uncover one of the most detrimental nuances of the work we do in software development: ASSUMPTION.

We begin with the idea from the Agile Manifesto (principle #5), which reminds us that,

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

To be clear, at the end of the day, we can all readily agree that “the most efficient and effective method” … … IS face to face… so how do we deal with this in the real world? (And yes, I live there too…)

We can use several methods if there isn’t the direct or immediate ability to do face to face:

  • Emailing
  • Phone conversations
  • Video Conferencing

If you track through these, one by one, you’ll see we’re moving from uni-lateral communication to bi-directional. Obviously bi-directional is far better… so the question we have to ask is:

“How can we move to the most effective methods to get work done?”

What we love to see, when we work with clients, are the powerful ways they change their operational support mechanisms to allow for powerful conversations to happen.

A little close for comfort? - But, we DID have great conversation that helped us build the right things!

A little close for comfort? – But, we DID have great conversation that helped us build the right things!

You don’t need to go far on a google search to find plenty of examples of how bringing people together to solve problems is pretty much the best way to do work!

Bringing people together to gain consensus on what we're committed to do!

Bringing people together to gain consensus on what we’re committed to do!

We invite you to find more about how we can help your organization build powerful software, services, or products. We’ve seen it done poorly. We’ve also been in the trenches long enough to know how to do it beautifully.

The post The Value of Planning Together appeared first on Agile For All.

Categories: Blogs

Using Scenarios for Experiment Design

lizkeogh.com - Elizabeth Keogh - Tue, 01/27/2015 - 15:49

In the complex domain, cause and effect are only correlated in retrospect, and we cannot predict outcomes. We can see them and understand them in retrospect, but the complex domain is the domain of discovery and innovation. Expect the unexpected! Every time we do something new which hasn’t been done before, or hasn’t been done within the given context, there are going to be complex aspects to it.

The only discovery-free project would be the same project, done with the same people, the same technology and the same requirements. That never happens!

Because of this, analysis doesn’t work for every aspect of a project. People who try to do analysis in the complex domain commonly experience analysis paralysis, thrashing, two-hour meetings led by “experts” who’ve never done it before either, and arguments about who’s to blame for the resulting discoveries.

Instead, the right thing to do is to probe; to design and perform experiments from which we can learn, and which will help to uncover information and develop expertise.

There are few things we can do to design experiments well, with thanks and credit for the strategies going to Cognitive Edge. (They have more material on this, available in their library if you sign up for free). Suggestions around scenarios are mine.

Amplification strategy; recovery strategy

For our experiment to work, we have to know how we’re going to amplify it. That may mean adding it to corporate processes, communicating it to a wider audience, automating it, releasing it to production, etc.. In the complex space doing the same thing over and over results in different outcomes because of the changing contexts, but once we understand cause and effect, we can start to test out that correlation in different or larger contexts, and develop expertise, moving it into the complicated domain.

We also need to have a strategy for recovery in case of failure. This doesn’t mean that we avoid failure!

I’ve seen a lot of people try to analyze their way out of every failure mode. One of my clients said, “Oh, but what if people don’t have the skills to do this experiment?” Does it matter? If the investment in the experiment is small enough (which is also part of being safe to fail) then all we need to know is that failure is safe; that we can recover from people not having skills. We don’t have to put everything in place to ensure success… and perhaps good things will happen from people being forced to gain skills, or using their existing skills to create a novel approach! This is the nature of experiments; that we don’t know the outcome, only that it has coherence, which means a reason for believing its impact, whatever it is, might be positive. More on that later.

If you can think of a scenario in which the experiment succeeds, can you think of how to make it succeed a second time, and then a third?

If you can think of a scenario in which it fails, can you think of how to make that failure safe (preferable to worrying about how to avoid the failure)? I find the evil hat very handy for thinking up failure scenarios.

Indications of failure; indications of success

In order to put into place our amplification or recovery strategies, we need to be able to tell whether an experiment is succeeding or failing. Metrics are fantastic for this. Don’t use them as tests, though, and definitely don’t use them as targets! They’re indicators; they may not behave as expected. We can understand the indicators in retrospect, but cause and effect won’t always be correlated until then.

As an example, one group I met decided to experiment to see if they could reduce their bug count by hiring a new team member and rotating an existing team member each week into a bug-fixing role. Their bug count started to go down! So they took another team member and hired another new person… but the bug count started to go up again.

It turned out that the users had spotted that bugs were being fixed, so they’d started reporting them. The bugs were always there! And the count of known bugs going up was actually a good thing.

Rather than thinking of tests, think of scenarios in which you can see the experiment succeeding or failing. Those things which allow you to see it – specific, measureable, relevant signs – will make for good indicators. These indicators will have to be monitored.

Rationale for Experiment

The experiment should be coherent.

This means that there should be a reason for believing the impact will be good, or as Dave Snowden puts it, “a sufficiency of evidence to allow us to progress“.

If you can come up with some realistic scenarios in which the experiment has a positive impact, you have coherence. The more likely the scenario is – and the more similar it is to scenarios you’ve seen in the past – then the more coherent it becomes, until the coherence is predictable and you have merely complicated problems, solvable with expertise, rather than complex ones.

To check that your scenarios are realistic, imagine yourself in the future, in that scenario. Where are you when you realise that the experiment has worked (or, if checking for safe failure, failed)? Who’s around you? What can you see? What can you hear? What colour are the walls, or if you’re outside, what else is around? Do you have a kinesthetic sense; something internal that tells  you that you’ve succeeded, like a feeling of pride or joy? This well-formed outcome will help you to verify that your scenario is realistic enough to be worth pursuing.

If you can’t come up with any scenarios in which you can imagine a positive impact, then your experiment is not coherent, and you might want to think of some other ideas.

Look out for a blog on how to do that with a shallow dive into chaos soon!


Categories: Blogs

Drei Wegweiser durch den Dschungel der täglichen Arbeit

Scrum 4 You - Tue, 01/27/2015 - 08:27

In meinem bisherigen Berufsleben haben sich drei zuverlässige Wegweiser durch diverse Höhen und Tiefen herauskristallisiert. Ich glaube, dass sie unabhängig vom Tätigkeitsbereich ziemlich nützlich sind – zumindest sind sie für mich als Change Manager und ScrumMaster eine gute Richtlinie in der täglichen Arbeit.

Fertig machen!

Egal, was ich tue und egal, wie schwierig es ist – eines trifft immer zu: Ich kann eine Tätigkeit zu Ende bringen. Früher habe ich an mir oft beobachtet, wie ich mitten in einem Thema schon zum nächsten gesprungen bin (siehe Synchronitis). Irgendwann wurde es zur Gewohnheit und ich hatte dabei das Gefühl, so wahnsinnig beschäftigt zu sein. Und irgendwie fühlte sich das gut an. Seltsam ist nur, dass ich meinem Scrum-Team etwas anderes beibringe: „Geht eine Sache nach der anderen an und macht die Dinge fertig. Parallel zu arbeiten führt nur zu Leistungsverlust.“ Und siehe da: Wenn man eine Sache nach der anderen macht, geht alles eine Spur leichter und nach jeder komplett abgeschlossenen Tätigkeit stellt sich ein Hochgefühl ein.

Konzentration auf das Mögliche

Als Change Manager sieht man so vieles, das einem nicht optimal erscheint. Man hat einen frischen Blick, man weiß, wie es woanders läuft und hat vor Augen, wie es hier auch besser laufen könnte. Dabei habe ich oft den Fehler gemacht, alle Dinge gleichzeitig anstoßen zu wollen und Dinge anzutreiben, die nicht angetrieben werden wollen. Dabei verliert man leider sehr viel Energie, die wesentlich besser dort eingesetzt werden könnte, wo man Dinge tatsächlich vorantreiben kann und das Umfeld positiv gestimmt ist. Auch wenn es manchmal schöner wäre, alles auf einmal umzusetzen, habe ich den positiven Effekt des Möglichen zu schätzen gelernt. Unmögliche Veränderungen sind meistens unmöglich, weil sie bei den beteiligten Personen Angst erzeugen. Durch die Erfolge mit den möglichen Dingen wächst bei diesen Beteiligten auch das Vertrauen in die eigene Person. Mit der Zeit ist dieses Vertrauen groß genug, dass einem die Beteiligten auch die Umsetzung von angstmachenden, sprich unmöglichen, Veränderungen zutrauen.

Fokus auf das Positive

Wir Menschen haben aufgrund unserer geistigen Fähigkeiten die Möglichkeit, Dinge in Relation zu ihrem Umfeld zu setzen. Interessanterweise ist diese Fähigkeit extrem subjektiv und sogar situationsabhängig. So mag das halb gefüllte Wasserglas an einem Tag als halb leer und am nächsten Tag als halb voll erscheinen. Wenn ich also einmal die eine oder andere Niederlage einstecken muss und mich frage “Wieso wird hier eigentlich NIE etwas verändert?“, setze ich mich hin und überlege, was hier eigentlich alles gut läuft. Die Erkenntnis am Ende des Tages ist eigentlich immer: Ich habe viel übersehen und eigentlich läuft auch vieles gut. Oft ist es nur eine Frage des Fokus.

Abgesehen davon, dass mir diese drei Wegweiser meine Arbeit erleichtern, mag ich sie vor allem wegen ihres menschlichen Aspekts. Sie machen mir und meinem Umfeld Mut, weiterzumachen und den nächsten Schritt auf dem Weg zu einer agilen Organisation zu gehen.

bamboo-364112_1280

Categories: Blogs

Programming with kids using LearnToMod and Minecraft

Henrik Kniberg's blog - Tue, 01/27/2015 - 06:34

I’ve spent years experimenting with how to teach kids programming, mostly using Scratch. But now we’ve found a new favorite: LearnToMod! Kids love Minecraft, and LearnToMod is entirely based on Minecraft, so it’s a perfect match!

We now do a Mod Club every Saturday evening, my older kids (9 & 11 years old) and some of their friends. It’s basically a programming school based on LearnToMod and Minecraft programming. Reeeeaaaally fun, the kids go wild (OK, me too)! AND they learn lots while doing it. To them it’s ”magic powers”, not “programming skills”.

I made a 5 minute video showing how it works:

LearnToMod provides almost 200 small programming lessons, starting from Hello World and then moving on to loops and functions and variables and all kinds of stuff. All lessons have really clear instructions and almost all of them involve something actually happening in the Minecraft world, which keeps it exciting. So kids can be pretty much self-guided, with just a little bit of support.

They use a visual programming language (Blockly, derived from Scratch). That’s great because it lets you focus on learning the program concepts, like loops and functions, without having to stumble around with detailed syntax. But since you can also see the Javascript behind the scenes, you can learn from that and write Javascript mods later. So the graphical programming is like a stepping stone (or gateway drug, if you prefer…).

As you progress you earn badges and points and other rewards, like inspiring video clips and things like that. It really does a lot to keep you going!

Last session we did a Mod Duel. The three kids got 30 minutes to prepare attack scripts against me (not allowed to use direct kill commands, but other more creative ways of attacking me, like burying me in sand or conjuring a prison cell full of monsters and teleporting me in), and I wrote defense scripts. Basically a duel where we only can use our “magic powers” (programming skills). I managed to survive one whole minute, not bad!

We’ve added another slight twist to our Mod Club sessions: a Lego house (yes, actual physical plastic bricks). Each kid has their own color, and on each completed lesson they “earn” a Lego brick in that color and use it to build on the house. That way, the house becomes a visual progress meter for the evening. This serves as a subtle reminder to keep doing the lessons and not spend the whole evening just goofing around. Goofing around is a great way to learn too, but some lessons are needed to learn new concepts (like loops, or parameterized function calls), and extend your magic powers!

Here are the kids proudly displaying their house from last session!

Kids programming

… and then back to programming:

Kids programming

Give LearnToMod a try! It works for grownups too :o)

Categories: Blogs

Knowledge Sharing


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