Skip to content

Feed aggregator

Why Coaching is Important

ScrumSense.com - Peter Hundermark - Tue, 10/14/2014 - 16:16
What is the Problem?

For people in 20th century organisations training was an obvious necessity. Just look at the still-classical organisation and see that it has a Training Department neatly tucked into the organisation chart just under Human Resources. (I hate that name…but I digress.)

Much changes in our post-industrial world where we think for a living, solving increasingly complex problems. Our paradigm for helping people be effective has not yet caught up.

What are the challenges?

  • We are solving hard problems. This requires the brains of multiple people to be aligned and work collectively to emerge solution options.
  • Failure remains stigmatised as something bad, rather than being recognised as an essential and desirable outcome of experimentation towards innovation.
  • We remain stuck in authoritative command-and-control cultures that fail to unlock the potential of people.
  • Employees acknowledge their own individual achievements, but less so their contribution to the result of a shared effort.
  • Managers have not yet grasped their new role as enablers rather than directors.
  • Most organisations reward individualism while hoping for teamwork.
  • …add yours here…
What is Coaching?

Professional coaching may be described as a method for helping a person or a team to achieve specific goals in their professional lives. Paraphrasing Kaltenecker and Myllerup: the coach acknowledges that the person or team being coached already has the potential abilities required for reaching the goals and the assignment for the coach is to help unlock this hidden potential.

An “agile coach” often steps into acting as a teacher, advisor, mentor or role model. Here she applies her own expertise to lead and guide the individual or team in specific ways. Yet as soon as possible she should return to a coaching stance to return appropriate the power balance to the relationship.

The diagram depicts the difference between when the “agile” coach is relying on her own expertise of the content as distinct from the systemic coach using her own ignorance of the full organisational context and applying curiosity as a powerful helping tool to build relationship.

Agile vs Systemic Coaching

Why Do We Need Coaching?

Ask any successful leader and she will tell you stories about the people who have helped her, formally and informally, along her journey.

In order to learn and grow we require honest feedback. Without enough trust, honest feedback is unlikely to be offered and received in a productive manner. Traditional work environments do not provide safety for trust to flourish.

And in the modern work context that requires collaboration to produce good results we need to develop new “soft” skills that we were not taught at university or technicon. Teams and individuals need to learn to be vulnerable to one another.

However it is not a given that we will ask for help. There are hard questions to answer, for example:

  • How do I recognise when I or my team needs help? Am I even capable of knowing what it is I don’t know (my blind spots)?
  • Why would my boss pay me a salary when I need outside help to do my job?
  • How does asking for help make me feel? I have to “lose face” to accept help from another.
  • …add your own…

In the South African cultural context where “cowboys don’t cry” and “boer maak ’n plan” it can be particularly hard to ask for help. And in the “controlling” and “competitive” styles of organisational cultures that still predominate worldwide it can be seen as a sign of weakness.

So many of us live with an unhealthy tension between needing help from others in order to grow, and the uncertainty about whether or when it’s okay to ask.

The coach as trusted external party is well-skilled and well-placed to facilitate the necessary conversations to help teams grow trust, deal with conflict and offer commitment that in turn lead to increased accountability and improved outcomes.

An Economic View

In work over nine years with more than 100 teams we have observed a marked difference between the extent and the pace of growth of individuals and teams that have received coaching and those who have “gone it alone” after, perhaps, a two-day training class.

An analysis of our own data shows a correlation between “performing” teams and the quantum of help. The sweet spot seems to be between one and two days of coaching per team member during the first year of transition. To be clear this includes all facets such as advising and organisational development. Our data does differentiate between individual and team coaching, yet clearly there is a need for both.

Benefits we have observed during and after coaching include:

  • Happier and more engaged team members
  • Reduced staff turnover
  • An increased sense of “we”
  • An increase in self-confidence and independence
  • Increases customer and stakeholder satisfaction through value delivery
  • Increased throughput and decreased “time to market”
  • Increased transparency and predictability

When asked how soon the benefits exceeded the costs, many clients have experienced improvement within a few weeks and the classic “J-curve” of change has not been felt. And it is not uncommon to hear “we have doubled/halved X compared with last quarter/year”.

Adding Perspective

Before we conclude that coaching is some “magic elixir”, let’s be clear that contexts differ and it is hard to attribute causality to a single element. Nevertheless we have many times heard “we should have got coaching earlier and had more of it”.

As Weick and Sutcliffe remind us in their excellent book about High Reliability Organisations, it is “a sign of strength to know when you’ve reached the limits of your knowledge and know enough to ask for help”.
¹Sigi Kaltenecker (Loop Organisationsberatung) & Bent Myllerup (agile42): Agile & Systemic Coaching
http://www.scrumalliance.org/community/articles/2011/may/agile-systemic-coaching

²Karl Weick and Kathleen Sutcliffe: Managing the Unexpected—Resilient Performance in an Age of Uncertainty (Second Edition, 2007, Wiley), page 80.

The post Why Coaching is Important appeared first on ScrumSense.

Categories: Blogs

Book List for Enterprise Agile Transformations

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

Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them.  This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent.  Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.

I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization.  It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile.  It is about urgency and need, and about a recognition that Agile is better than not-Agile.  If you aren’t in that situation, this is not the book list for you.

Culture

These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture.  Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments.  These books all touch on culture in various ways, and build on the ideas in the books about culture.  For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

Agile at Scale

These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg

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

Scaling Agile Your Way: How to Develop and Implement Your Custom Approach (Part 4 of 4)

Agile Management Blog - VersionOne - Tue, 10/14/2014 - 14:46

In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.  In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (Tables 1-4 of Part 1).   I also presented a brief overview of various popular agile and lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.

Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.  SAFe and MAXOS represent radically different approaches to scaling agile. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

In Part 3, I presented the Sweet Spots, Challenge Zones and Unfit zones for SAFe and MAXOS. Figure 1 in Part 3 illustrated the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presented similar information for MAXOS.  The Sweet spot indicates a good match between a scaling agile framework and all scaling agile parameters; consequently the implementation becomes easier, more efficient and effective.  The Challenge Zone indicates a challenging match between a framework and one or more scaling agile parameters, and requires more implementation effort compared to the Sweet Spot.  The Unfit Zone indicates a very poor (almost unworkable) match between a framework and one or more scaling agile parameters.

In Part 3, I explained why it is a good idea to get as close as possible to the sweet spot of your chosen scaling agile framework; it increases the likelihood that your pilot large-scale agile project will have fewer difficulties in succeeding. If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The root cause is likely to be one of these two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate their understanding and commitment to the success of scaling agile.

2.  Arising from the market and business environment of your organization.  These pressures cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment some of the scaling agile framework practices with your own custom practices, while retaining the practices from the framework that are still applicable.

The journey from Unfit or Challenge Zone to Sweet Spot is uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but may still have a few areas in the Challenge Zone to address.

In this final part of my series, I explain a very important challenge for Scaling Agile Your Way.  It requires each team, program or portfolio to implement one or more key aspects of the chosen framework (whether the key aspect is in the Sweet Spot or Challenge Zone) in unique and customized ways.  I explain how the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be applied to SAFe to make it less prescriptive, “modularize” SAFe, and allow customized implementation of those modules.

The Scrum at Scale framework provides a general language for talking about how to scale Scrum.  At its roots, Scrum is an object-oriented framework.  Each role, artifact and ceremony is defined by the teams’ objectives, participants, inputs and outputs.  Core Scrum allows for many different ways to achieve objectives within given input/output constraints. Modularity allows organizations to establish and improve agile practices incrementally by focusing on one independent module at a time.  Scrum at Scale aspires to develop a “pattern library” of successful approaches that can be used in different contexts; this pattern library is being developed based on a crowd-sourcing approach.

Tables 12-16 in this post (see below) present 10 modules of the Scrum at Scale framework:

1.  Team-Level Scrum Process
2.  Strategic Vision
3.  Backlog Prioritization
4.  Backlog Decomposition and Refinement
5.  Release Planning
6.  Release Management
7.  Feedback
8.  Continuous Improvement and Impediment Removal
9.  Cross-Team Coordination
10. Metrics and Transparency

As the Scrum framework is object-oriented, each of these 10 modules has a set of well-defined goals, inputs and outputs.  It is up to each entity (team or business unit or organization) to implement each module in a way that best suits its own needs and constraints, so long as it produces the desired goals and outputs from a given set of inputs.  The details of implementing each module should be left to each entity, as the implementation details are expected to be different.  Each of Tables 12-16 presents two modules and explains how object-oriented implementation of each module is applicable to SAFe.

SAFe is characterized by its critics as too prescriptive; some of this critique may be fair while other is not.  Critics allege that because SAFe is (overly) prescriptive, it may not work well in many situations.  This prescriptive orientation (real or perceived) of SAFe can be reduced considerably by taking a strong, object-oriented approach in modularizing and implementing SAFe.  Instead of prescribing or specifying how different goals or ceremonies of SAFe should be implemented, why not follow the object-oriented approach of Scrum at Scale framework while implementing SAFe — where each module’s goals, outputs and inputs are emphasized while leaving the implementation details to each entity (team or program or portfolio)?  Of course, constraints arising from inter-team or inter-program coordination and synchronization must be met; even those constraints should be specified in terms of their goals — not by prescribing their implementation details (think of “object-oriented” constraints). 

Table 12:  Modules 1 and 2 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table12

 

Table 13:  Modules 3 and 4 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table13

Table 14:  Modules 5 and 6 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table14

Table 15: Modules 7 and 8 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table15

Table 16: Modules 9 and 10 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table16Customization needs and opportunities for the MAXOS framework

These will arise mostly in the context of implementing its advanced engineering practices of:

  • Code contribution
  • Automated testing
  • Continuous integration
  • Feature switches
  • Continuous delivery
  • Collecting and analyzing automated user feedback
  • Making use of cloud computing facilities on a massive scale, etc.

There are open-source and some commercial products available for automated testing, continuous integration and using cloud computing facilities for software development, testing and deployment.  I will not elaborate on MAXOS customization here.

How may an object-oriented implementation of SAFe (applying Scrum at Scale meta-framework guidelines, as explained in this part) suit your organization’s needs and constraints better than following SAFe “by the book?”  Besides the aspects of customization covered in Tables 12-16, are there any other aspects that come to your mind?  I would love to hear from you on these questions or any aspect of this four-part blog series, either here, by email (Satish.Thatte@VersionOne.com), or on
Twitter @smthatte.

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Part 3: Scaling Agile Your Way:  Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS

Categories: Companies

No More Business as Usual

Rally Agile Blog - Tue, 10/14/2014 - 14:00

When the S&P 500 index was created in 1957, the average expected lifespan of a company on the index was 61 years. By 1980 that lifespan had been cut in half, and in the coming decade it likely will be halved again. What used to be a health index for stable companies is now a thermometer for the fluctuating temperatures of disruptive markets.

The S&P is just one indicator of the evolving environment for businesses. Markets are now global and highly responsive. Competition moves at startup speed. Operational efficiency isn’t a nice-to-have, it’s a necessity. Customers, and their expectations, hold more sway than any executive. And at the heart of all these changes is a technology backbone, accelerating both the opportunities for innovation and the impact of competitive threats.

Adapt or Die

Woolworth’s. Kodak. Blockbuster. Borders. The list of companies that couldn’t survive in this new environment is long and growing.

“Big companies that fail to innovate risk extinction,” says the BBC. “That's the stark truth in the era of 'digital disruption.'"

Being a big fish doesn’t make you immune and being a small fish doesn't make you competitive; disruption will affect nearly every business in some way, it's just a question of how ... and when.

Agility: The Competitive Advantage

What makes some companies survive – and thrive – in this kind of environment, and how can you become one of those companies?

Those that successfully navigate today’s competitive markets know how to sense, create, and respond to change, and they can do it quickly and confidently.

Agility throughout an organization can 'spell the difference between being severely disrupted, or turning the disruption from a threat to a competitive advantage – an opportunity to develop new products, service, markets and business models to help propel the company into the future.'”

These companies don't just practice agile in their software development; they are agile businesses

  • They improve and scale their software development performance so they can deliver more value to customers, faster.
  • They connect their software development performance to business strategy, building flexible portfolio management that adapts quickly to market changes and optimizes for business value.
  • They invest the dividends of their performance gains in market-leading innovation, running experiments and getting fast customer feedback.

Learn how to build agility into your company’s DNA. Download the new Rally Business Agility Survival Guide and get started.

Rally Software
Categories: Companies

Poor Uses for Transparency

Agile Tools - Tue, 10/14/2014 - 08:17

architecture-blue-sky-building-563-825x550

In the Agile world we do a lot of things to try and create transparency within our organizations. We put up information radiators like burn down charts, task boards, and cumulative flow diagrams. We put information up on the walls with sticky notes everywhere you turn. We have team synchronization meetings every day. There’s a lot of information flowing around, so is it even possible that transparency can be misused? Is it possible for transparency to go wrong?

In most cases, I think my default answer to this question would be “no” – in general, I’ll take transparency anytime. However I have run across a few situations with transparency that have made me tear my hair out. There are three different cases that I’m thinking of: Frequency of request, Lack of Decisions, and Missing the point: value.

Updating status information on a regular, even frequent, basis can be useful – especially if the work is high priority. However, there is an upper limit beyond which frequent reporting becomes counter productive. It’s one thing to update status once a week, but when it becomes once a day, something has gone wrong. I’m not really sure that there is a discrete boundary beyond which the reporting becomes too much. All I can say is that you know it when you cross it. The problem is, it ends up creating more churn than productive action.

Transparency isn’t all that useful if it doesn’t lead to meaningful action. A lack of decisions is usually an indicator that there is dysfunction that the transparency is not helping to address. In fact, what you are probably finding is that you are only getting superficial transparency. The question is, why aren’t the decisions getting made?

Finally, transparency is only effective if it helps to understand how the organization delivers value. Often times transparency focuses on things that don’t reflect business value. This is missing the point of transparency. It needs to remain focused on the business value.


Filed under: Agile, Process Tagged: communication, reporting, status, transparency, visibility
Categories: Blogs

AngularJS Training Week

Xebia Blog - Tue, 10/14/2014 - 08:00

Just a few more weeks and it's the AngularJS Training Week at Xebia in Hilversum (The Netherlands). 4 days packed with AngularJS content, from 17 to 20 October, 2014. On these different days we will cover the AngularJS basics, AngularJS advanced topics, Tooling & Scaffolding and Testing with Jasmine, Karma and Protractor.

If you already have some experience or if you are only interested in one or two of the topics, then you can sign up for just the days that are of interest to you.

Visit www.angular-training.com for a full overview of the days and topics or sign up on the Xebia Training website using the links below.

Categories: Companies

5 Decision-Making Strategies that require no estimates

Software Development Today - Vasco Duarte - Tue, 10/14/2014 - 05:00

One of the questions that I and other #NoEstimates proponents hear quite often is: How can we make decisions on what projects we should do next, without considering the estimated time it takes to deliver a set of functionality?

Although this is a valid question, I know there are many alternatives to the assumptions implicit in this question. These alternatives - which I cover in this post - have the side benefit of helping us focus on the most important work to achieve our business goals.

Below I list 5 different decision-making strategies (aka decision making models) that can be applied to our software projects without requiring a long winded, and error prone, estimation process up front.

What do you mean by decision-making strategy?

A decision-making strategy is a model, or an approach that helps you make allocation decisions (where to put more effort, or spend more time and/or money). However I would add one more characteristic: a decision-making strategy that helps you chose which software project to start must help you achieve business goals that you define for your business. More specifically, a decision-making strategy is an approach to making decisions that follows your existing business strategy.

Some possible goals for business strategies might be:

  • Growth: growing the number of customer or users, growing revenues, growing the number of markets served, etc.
  • Market segment focus/entry: entering a new market or increasing your market share in an existing market segment.
  • Profitability: improving or maintaining profitability.
  • Diversification: creating new revenue streams, entering new markets, adding products to the portfolio, etc.

Other types of business goals are possible, and it is also possible to mix several goals in one business strategy.

Different decision-making strategies should be considered for different business goals. The 5 different decision-making strategies listed below include examples of business goals they could help you achieve. But before going further, we must consider one key aspect of decision making: Risk Management.

The two questions that I will consider when defining a decision-making strategy are:

  • 1. How well does this decision proposal help us reach our business goals?
  • 2. Does the risk profile resulting from this decision fit our acceptable risk profile?

Are you taking into account the risks inherent in the decisions made with those frameworks?

All decisions have inherent risks, and we must consider risks before elaborating on the different possible decision-making strategies. If you decide to invest in a new and shiny technology for your product, how will that affect your risk profile?

A different risk profile requires different decisions

Each decision we make has an impact on the following risk dimensions:

  • Failing to meet the market needs (the risk of what).
  • Increasing your technical risks (the risk of how).
  • Contracting or committing to work which you are not able to staff or assign the necessary skills (the risk of who).
  • Deviating from the business goals and strategy of your organization (the risk of why).

The categorization above is not the only possible. However it is very practical, and maps well to decisions regarding which projects to invest in.

There may good reasons to accept increasing your risk exposure in one or more of these categories. This is true if increasing that exposure does not go beyond your acceptable risk profile. For example, you may accept a larger exposure to technical risks (the risk of how), if you believe that the project has a very low risk of missing market needs (the risk of what).

An example would be migrating an existing product to a new technology: you understand the market (the product has been meeting market needs), but you will take a risk with the technology with the aim to meet some other business need.

Aligning decisions with business goals: decision-making strategies

When making decisions regarding what project or work to undertake, we must consider the implications of that work in our business or strategic goals, therefore we must decide on the right decision-making strategy for our company at any time.

Decision-making Strategy 1: Do the most important strategic work first

If you are starting to implement a new strategy, you should allocate enough teams, and resources to the work that helps you validate and fine tune the selected strategy. This might take the form of prioritizing work that helps you enter a new segment, or find a more valuable niche in your current segment, etc. The focus in this decision-making approach is: validating the new strategy. Note that the goal is not "implement new strategy", but rather "validate new strategy". The difference is fundamental: when trying to validate a strategy you will want to create short-term experiments that are designed to validate your decision, instead of planning and executing a large project from start to end. The best way to run your strategy validation work is to the short-term experiments and re-prioritize your backlog of experiments based on the results of each experiment.

Decision-making Strategy 2: Do the highest technical risk work first

When you want to transition to a new architecture or adopt a new technology, you may want to start by doing the work that validates that technical decision. For example, if you are adopting a new technology to help you increase scalability of your platform, you can start by implementing the bottleneck functionality of your platform with the new technology. Then test if the gains in scalability are in line with your needs and/or expectations. Once you prove that the new technology fulfills your scalability needs, you should start to migrate all functionality to the new technology step by step in order of importance. This should be done using short-term implementation cycles that you can easily validate by releasing or testing the new implementation.

Decision-making Strategy 3: Do the easiest work first

Suppose you just expanded your team and want to make sure they get to know each other and learn to work together. This may be due to a strategic decision to start a new site in a new location. Selecting the easiest work first will give the new teams an opportunity to get to know each other, establish the processes they need to be effective, but still deliver concrete, valuable working software in a safe way.

Decision-making Strategy 4: Do the legal requirements first

In medical software there are regulations that must be met. Those regulations affect certain parts of the work/architecture. By delivering those parts first you can start the legal certification for your product before the product is fully implemented, and later - if needed - certify the changes you may still need to make to the original implementation. This allows you to improve significantly the time-to-market for your product. A medical organization that successfully adopted agile, used this project decision-making strategy with a considerable business advantage as they were able to start selling their product many months ahead of the scheduled release. They were able to go to market earlier because they successfully isolated and completed the work necessary to certify the key functionality of their product. Rather then trying to predict how long the whole project would take, they implemented the key legal requirements first, then started to collect feedback about the product from the market - gaining a significant advantage over their direct competitors.

Decision-making Strategy 5: Liability driven investment model

This approach is borrowed from a stock exchange investment strategy that aims to tackle a problem similar to what every bootstrapped business faces: what work should we do now, so that we can fund the business in the near future? In this approach we make decisions with the aim of generating the cash flows needed to fund future liabilities.

These are just 5 possible investment or decision-making strategies that can help you make project decisions, or even business decisions, without having to invest in estimation upfront.

None of these decision-making strategies guarantees success, but then again nothing does except hard work, perseverance and safe experiments!

In the upcoming workshops (Helsinki on Oct 23rd, Stockholm on Oct 30th) that me and Woody Zuill are hosting, we will discuss these and other decision-making strategies that you can take and start applying immediately. We will also discuss how these decision making models are applicable in day to day decisions as much as strategic decisions.

If you want to know more about what we will cover in our world-premiere #NoEstimates workshops don't hesitate to get in touch!

Your ideas about decision-making strategies that do not require estimation

You may have used other decision-making strategies that are not covered here. Please share your stories and experiences below so that we can start collecting ideas on how to make good decisions without the need to invest time and money into a wasteful process like estimation.

Categories: Blogs

The Hard Thing About Hard Things – Ben Horowitz: Book Review

Mark Needham - Tue, 10/14/2014 - 01:59

I came across ‘The Hard Thing About Hard Things‘ while reading an article about Ben Horowitz’s venture capital firm and it was intriguing enough that I bought it and then read through it over a couple of days.

Although the blurb suggests that it’s a book about about building and running a startup I think a lot of the lessons are applicable for any business.

These were some of the main points that stood out for me:

  • The Positivity Delusion – CEOs should tell it like it is.

    My single biggest improvement as CEO occurred on the day when I stopped being too positive.

    Horowitz suggests that he used to be too positive and would shield bad news from his employees as he thought he’d make the problem worse by transferring the burden onto them.

    He came to the realisation that this was counter productive since he often wasn’t the best placed person to fix a problem e.g. if it was a problem with the product then the engineering team needed to know so they could write the code to fix it.

    He goes on to suggest that…

    A healthy company culture encourages people to share bad news. A company that discusses its problems freely and openly can quickly solve them. A company that covers up its problems frustrated everyone involved.

    I’ve certainly worked on projects in the past where the view projected by the most senior person is overly positive and seems to ignore any problems that seem obvious to everyone else. This eventually leads to people being unsure whether to take them seriously which isn’t a great situation to be in.

  • Lead Bullets – fix the problem, don’t run away from it.

    Horowitz describes a couple of situations where his products have been inferior to their competitors and it’s been tempting to take the easy way out by not fixing the product.

    There comes a time in every company’s life where it must fight for its life. If you find yourself running when you should be fighting, you need to ask yourself, “If our company isn’t good enough to win, then do we need to exist at all?”.

    I can’t think of any examples around this from my experience but I really like the advice – I’m sure it’ll come in handy in future.

  • Give ground grudgingly – dealing with the company increasing in size.

    Horowitz suggests that the following things become more difficult as a company grows in size:

    • Communication
    • Common Knowledge
    • Decision Making

    but…

    If the company doesn’t expand it will never be much…so the challenge is to grow but degrade as slowly as possible.

    He uses the metaphor of an offensive linesman in American football who has to stop onrushing defensive linesman but giving ground to them slowly by backing up a little at a time.

    I’ve worked in a few different companies now and noticed things become more structured (and in my eyes worse!) as the company grew over time but I hadn’t really thought about why that was happening. The chapter on scaling a company does a decent job.

  • The Law of Crappy People – people baseline against the worst person at a grade level.

    For any title level in a large organisation, the talent on that level will eventually converge to the crappiest person with that title.

    This is something that he’s also written about on his blog and certainly seems very recognisable.

    His suggestion for mitigating the problem is to have a “properly constructed and highly disciplined promotion process” in place. He describes this like so:

    When a manager wishes to promote an employee, she will submit that employee for review with an explanation of why she believes her employee satisfies the skill criteria required for the level.

    The committee should compare the employee to both the level’s skill description and the skills of the other employees at that level to determine whether or not to approve the promotion.

  • Hire people with the right kind of ambition

    The wrong kind of ambition is ambition for the executive’s personal success regardless of the company’s outcome.

    This suggestion comes from the chapter in which Horowitz discusses how to minimise politics in an organisation.

    I really like this idea but it seems like a difficult thing to judge/achieve. In my experience people often have their own goals which aren’t necessarily completely aligned with the company’s. Perhaps complete alignment isn’t as important unless you’re right at the top of the company?

    He also has quite a neat definition of politics:

    What do I mean by politics? I mean people advancing their careers or agendas by means other than merit and contribution.

    He goes on to describe a few stories of how political behaviour can subtly creep into a company without the CEO meaning for it to happen. This chapter was definitely eye opening for me.

There are some other interesting chapters on the best types of CEOs for different companies, when to hire Senior external people, product management and much more.

I realise that the things I’ve picked out are mostly a case of confirmation bias so I’m sure everyone will have different things that stand out for them.

Definitely worth a read.

Categories: Blogs

Agile Beyond Software

TV Agile - Mon, 10/13/2014 - 21:09
Agile is most closely associated with software development, Agile software development to be precise. That’s enough to put people off right there and then. But for those who listen long enough invariably ask the big question: “Does Agile work outside of software?” This is the question Allan Kelly will attempt to answer in this presentation. […]
Categories: Blogs

Fast and Easy integration testing with Docker and Overcast

Xebia Blog - Mon, 10/13/2014 - 19:40
Challenges with integration testing

Suppose that you are writing a MongoDB driver for java. To verify if all the implemented functionality works correctly, you ideally want to test it against a REAL MongoDB server. This brings a couple of challenges:

  • Mongo is not written in java, so we can not embed it easily in our java application
  • We need to install and configure MongoDB somewhere, and maintain the installation, or write scripts to set it up as part of our test run.
  • Every test we run against the mongo server, will change the state, and tests might influence each other. We want to isolate our tests as much as possible.
  • We want to test our driver against multiple versions of MongoDB.
  • We want to run the tests as fast as possible. If we want to run tests in parallel, we need multiple servers. How do we manage them?

Let's try to address these challenges.

First of all, we do not really want to implement our own MonogDB driver. Many implementations exist and we will be reusing the mongo java driver to focus on how one would write the integration test code.

Overcast and Docker

logoWe are going to use Docker and Overcast. Probably you already know Docker. It's a technology to run applications inside software containers. Overcast is the library we will use to manage docker for us. Overcast is a open source java library
developed by XebiaLabs to help you to write test that connect to cloud hosts. Overcast has support for various cloud platforms, including EC2, VirtualBox, Vagrant, Libvirt (KVM). Recently support for Docker has been added by me in Overcast version 2.4.0.

Overcast helps you to decouple your test code from the cloud host setup. You can define a cloud host with all its configuration separately from your tests. In your test code you will only refer to a specific overcast configuration. Overcast will take care of creating, starting, provisioning that host. When the tests are finished it will also tear down the host. In your tests you will use Overcast to get the hostname and ports for this cloud host to be able to connect to them, because usually these are dynamically determined.

We will use Overcast to create Docker containers running a MongoDB server. Overcast will help us to retrieve the dynamically exposed port by the Docker host. The host in our case will always be the docker host. Docker in our case runs on an external Linux host. Overcast will use a TCP connection to communicate with Docker. We map the internal ports to a port on the docker host to make it externally available. MongoDB will internally run on port 27017, but docker will map this port to a local port in the range 49153 to 65535 (defined by docker).

Setting up our tests

Lets get started. First, we need a Docker image with MongoDB installed. Thanks to the Docker community, this is as easy as reusing one of the already existing images from the Docker Hub. All the hard work of creating such an image is already done for us, and thanks to containers we can run it on any host capable of running docker containers. How do we configure Overcast to run the MongoDB container? This is our minimal configuration we put in a file called overcast.conf:

mongodb {
    dockerHost="http://localhost:2375"
    dockerImage="mongo:2.7"
    exposeAllPorts=true
    remove=true
    command=["mongod", "--smallfiles"]
}

That's all! The dockerHost is configured to be localhost with the default port. This is the default value and you can omit this. The docker image called mongo version 2.7 will be automatically pulled from the central docker registry. We set exposeAllPorts to true to inform docker it needs to dynamically map all exposed ports by the docker image. We set remove to true to make sure the container is automatically removed when stopped. Notice we override the default container startup command by passing in an extra parameter "--smallfiles" to improve testing performance. For our setup this is all we need, but overcast also has support for defining static port mappings, setting environment variables, etc. Have a look at the Overcast documentation for more details.

How do we use this overcast host in our test code? Let's have a look at the test code that sets up the Overcast host and instantiates the mongodb client that is used by every test. The code uses the TestNG @BeforeMethod and @AfterMethod annotations.

private CloudHost itestHost;
private Mongo mongoClient;

@BeforeMethod
public void before() throws UnknownHostException {
    itestHost = CloudHostFactory.getCloudHost("mongodb");
    itestHost.setup();

    String host = itestHost.getHostName();
    int port = itestHost.getPort(27017);

    MongoClientOptions options = MongoClientOptions.builder()
        .connectTimeout(300 * 1000)
        .build();

    mongoClient = new MongoClient(new ServerAddress(host, port), options);
    logger.info("Mongo connection: " + mongoClient.toString());
}

@AfterMethod
public void after(){
    mongoClient.close();
    itestHost.teardown();
}

It is important to understand that the mongoClient is the object under test. Like mentioned before, we borrowed this library to demonstrate how one would integration test such a library. The itestHost is the Overcast CloudHost. In before(), we instantiate the cloud host by using the CloudHostFactory. The setup() will pull the required images from the docker registry, create a docker container, and start this container. We get the host and port from the itestHost and use them to build our mongo client. Notice that we put a high connection timeout on the connection options, to make sure the mongodb server is started in time. Especially the first run it can take some time to pull images. You can of course always pull the images beforehand. In the @AfterMethod, we simply close the connection with mongoDB and tear down the docker container.

Writing a test

The before and after are executed for every test, so we will get a completely clean mongodb server for every test, running on a different port. This completely isolates our test cases so that no tests can influence each other. You are free to choose your own testing strategy, sharing a cloud host by multiple tests is also possible. Lets have a look at one of the tests we wrote for mongo client:

@Test
public void shouldCountDocuments() throws DockerException, InterruptedException, UnknownHostException {

    DB db = mongoClient.getDB("mydb");
    DBCollection coll = db.getCollection("testCollection");
    BasicDBObject doc = new BasicDBObject("name", "MongoDB");

    for (int i=0; i < 100; i++) {
        WriteResult writeResult = coll.insert(new BasicDBObject("i", i));
        logger.info("writing document " + writeResult);
    }

    int count = (int) coll.getCount();
    assertThat(count, equalTo(100));
}

Even without knowledge of MongoDB this test should not be that hard to understand. It creates a database, a new collection and inserts 100 documents in the database. Finally the test asserts if the getCount method returns the correct amount of documents in the collection. Many more aspects of the mongodb client can be tested in additional tests in this way. In our example setup, we have implemented two more tests to demonstrate this. Our example project contains 3 tests. When you run the 3 example tests sequentially (assuming the mongo docker image has been pulled), you will see that it takes only a few seconds to run them all. This is extremely fast.

Testing against multiple MongoDB versions

We also want to run all our integration tests against different versions of the mongoDB server to ensure there are no regressions. Overcast allows you to define multiple configurations. Lets add configuration for two more versions of MongoDB:

defaultConfig {
    dockerHost="http://localhost:2375"
    exposeAllPorts=true
    remove=true
    command=["mongod", "--smallfiles"]
}

mongodb27=${defaultConfig}
mongodb27.dockerImage="mongo:2.7"

mongodb26=${defaultConfig}
mongodb26.dockerImage="mongo:2.6"

mongodb24=${defaultConfig}
mongodb24.dockerImage="mongo:2.4"

The default configuration contains the configuration we have already seen. The other three configurations extend from the defaultConfig, and define a specific mongoDB image version. Lets also change our test code a little bit to make the overcast configuration we use in the test setup depend on a parameter:

@Parameters("overcastConfig")
@BeforeMethod
public void before(String overcastConfig) throws UnknownHostException {
    itestHost = CloudHostFactory.getCloudHost(overcastConfig);

Here we used the paramaterized tests feature from TestNG. We can now define a TestNG suite to define our test cases and how to pass in the different overcast configurations. Lets have a look at our TestNG suite definition:

<suite name="MongoSuite" verbose="1">
    <test name="MongoDB27tests">
        <parameter name="overcastConfig" value="mongodb27"/>
        <classes>
            <class name="mongo.MongoTest" />
        </classes>
    </test>
    <test name="MongoDB26tests">
        <parameter name="overcastConfig" value="mongodb26"/>
        <classes>
            <class name="mongo.MongoTest" />
        </classes>
    </test>
    <test name="MongoDB24tests">
        <parameter name="overcastConfig" value="mongodb24"/>
        <classes>
            <class name="mongo.MongoTest" />
        </classes>
    </test>
</suite>

With this test suite definition we define 3 test cases that will pass a different overcast configuration to the tests. The overcast configuration plus the TestNG configuration enables us to externally configure against which mongodb versions we want to run our test cases.

Parallel test execution

Until this point, all tests will be executed sequentially. Due to the dynamic nature of cloud hosts and docker, nothing limits us to run multiple containers at once. Lets change the TestNG configuration a little bit to enable parallel testing:

<suite name="MongoSuite" verbose="1" parallel="tests" thread-count="3">

This configuration will cause all 3 test cases from our test suite definition to run in parallel (in other words our 3 overcast configurations with different MongoDB versions). Lets run the tests now from IntelliJ and see if all tests will pass:

Screen Shot 2014-10-08 at 8.32.38 PM
We see 9 executed test, because we have 3 tests and 3 configurations. All 9 tests have passed. The total execution time turned out to be under 9 seconds. That's pretty impressive!

During test execution we can see docker starting up multiple containers (see next screenshot). As expected it shows 3 containers with a different image version running simultaneously. It also shows the dynamic port mappings in the "PORTS" column:

Screen Shot 2014-10-08 at 8.50.07 PM

That's it!

Summary

To summarise, the advantages of using Docker with Overcast for integration testing are:

  1. Minimal setup. Only a docker capable host is required to run the tests.
  2. Save time. Minimal amount of configuration and infrastructure setup required to run the integration tests thanks to the docker community.
  3. Isolation. All test can run in their isolated environment so the tests will not affect each other.
  4. Flexibility. Use multiple overcast configuration and parameterized tests for testing against multiple versions.
  5. Speed. The docker container starts up very quickly, and overcast and testng allow you to even parallelize the testing by running multiple containers at once.

The example code for our integration test project is available here. You can use Boot2Docker to setup a docker host on Mac or Windows.

Happy testing!

Paul van der Ende 

Note: Due to a bug in the gradle parallel test runner you might run into this random failure when you run the example test code yourself. The work around is to disable parallelism or use a different test runner like IntelliJ or maven.

 

Categories: Companies

How Digital is Changing Physical Experiences

J.D. Meier's Blog - Mon, 10/13/2014 - 18:12

The business economy is going through massive change, as the old world meets the new world.

The convergence of mobility, analytics, social media, cloud computing, and embedded devices is driving the next wave of digital business transformation, where the physical world meets new online possibilities.

And it’s not limited to high-tech and media companies.

Businesses that master the digital landscape are able to gain strategic, competitive advantage.   They are able to create new customer experiences, they are able to gain better insights into customers, and they are able to respond to new opportunities and changing demands in a seamless and agile way.

In the book, Leading Digital: Turning Technology into Business Transformation: Turning Technology Into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of the ways that businesses are meshing the physical experience with the digital experience to generate new business value.

Provide Customers with an Integrated Experience

Businesses that win find new ways to blend the physical world with the digital world.  To serve customers better, businesses are integrating the experience across physical, phone, mail, social, and mobile channels for their customers.

Via Leading Digital: Turning Technology into Business Transformation:

“Companies with multiple channels to customers--physical, phone, mail, social, mobile, and so on--are experiencing pressure to provide an integrated experience.  Delivering these omni-channel experiences requires envisioning and implementing change across both front-end and operational processes.  Innovation does not come from opposing the old and the new.  But as Burberry has shown,  innovation comes from creatively meshing the digital and the physical to reinvent new and compelling customer experiences and to foster continuous innovation.”

Bridge In-Store Experiences with New Online Possibilities

Starbucks is a simple example of blending digital experiences with their physical store.   To serve customers better, they deliver premium content to their in-store customers.

Via Leading Digital: Turning Technology into Business Transformation:

“Similarly, the unique Starbucks experience is rooted in connecting with customers in engaging ways.  But Starbucks does not stop with the physical store.  It has digitally enriched the customer experience by bridging its local, in-store experience with attractive new online possibilities.  Delivered via a free Wi-Fi connection, the Starbucks Digital Network offers in-store customers premium digital content, such as the New York Times or The Economist, to enjoy alongside their coffee.  The network also offers access to local content, from free local restaurant reviews from Zagat to check-in via Foursquare.”

An Example of Museums Blending Technology + Art

Museums can create new possibilities by turning walls into digital displays.  With a digital display, the museum can showcase all of their collections and provide rich information, as well as create new backdrops, or tailor information and tours for their customers.

Via Leading Digital: Turning Technology into Business Transformation:

“Combining physical and digital to enhance customer experiences is not limited to just commercial enterprises.  Public services are getting on the act.  The Cleveland Museum of Art is using technology to enhance the experience and the management of visitors.  'EVERY museum is searching for this holy grail, this blending of technology and art,' said David Franklin, the director of the museum.

 

Fort-foot-wide touch screens display greeting-card sized images of all three thousand objects, and offers information like the location of the actual piece.  By touching an icon on the image, visitors can transfer it from the wall to an iPad (their own, or rented from the museum for $5 a day), creating a personal list of favorites.  From this list, visitors can design a personalized tour, which they can share with others.

 

'There is only so much information you can put on a wall, and no one walks around with catalogs anymore,' Franklin said.  The app can produce a photo of the artwork's original setting--seeing a tapestry in a room filled with tapestries, rather than in a white-walled gallery, is more interesting.  Another feature lets you take the elements of a large tapestry and rearrange them in either comic-book or movie-trailer format.  The experience becomes fun, educational, and engaging.  This reinvention has lured new technology-savvy visitors, but has also made seasoned museum-goers come more often.”

As you figure out the future capability vision for your business, and re-imagine what’s possible, consider how the Nexus of Forces (Cloud, Mobile, Social, and Big Data), along with the mega mega-trend (Internet-of-Things), can help you shape your digital business transformation.

You Might Also Like

Cloud Changes the Game from Deployment to Adoption

Management Innovation is at the Top of the Innovation Stack

McKinsey on Unleashing the Value of Big Data Analytics

Categories: Blogs

Manage Agile, Berlin, Germany, October 27-30 2014

Scrum Expert - Mon, 10/13/2014 - 17:32
Manage Agile is a four day conference focused on Agile management topics – no pure technologic aspects. The Manage Agile conference is a networking platform where specialists and managers discuss agile topics not only in software engineering but also in the whole company up to the management. The conference is divided into two workshop days and two conference days. Most of the presentations are in German, but you will also find English content. In the agenda of Manage Agile you can find topics like “The roots of Agile and Lean in ...
Categories: Communities

Xebia KnowledgeCast Episode 5: Madhur Kathuria and Scrum Day Europe 2014

Xebia Blog - Mon, 10/13/2014 - 11:48

xebia_xkc_podcast
The Xebia KnowledgeCast is a bi-weekly podcast about software architecture, software development, lean/agile, continuous delivery, and big data. Also, we'll have some fun with stickies!

In this 5th episode, we share key insights of Madhur Kathuria, Xebia India’s Director of Agile Consulting and Transformation, as well as some impressions of our Knowledge Exchange and Scrum Day Europe 2014. And of course, Serge Beaumont will have Fun With Stickies!

First, Madhur Kathuria shares his vision on Agile and we interview Guido Schoonheim at Scrum Day Europe 2014.

In this episode's Fun With Stickies Serge Beaumont talks about wide versus deep retrospectives.

Then, we interview Martin Olesen and Patricia Kong at Scrum Day Europe 2014.

Want to subscribe to the Xebia KnowledgeCast? Subscribe via iTunes, or use our direct rss feed.

Your feedback is appreciated. Please leave your comments in the shownotes. Better yet, send in a voice message so we can put you ON the show!

Credits

Categories: Companies

Design Thinking für Product Owner – Teil 5: Wie entstehen eigentlich gute Ideen?

Scrum 4 You - Mon, 10/13/2014 - 07:30

Unser Gehirn vermag Erstaunliches. Wie wäre es, wenn wir mehr von diesem Potential zur Problemlösung nutzen würden? Sicher haben auch Sie schon den Spruch gehört: “Kreative arbeiten am stärksten, wenn es aussieht, als ob sie gar nichts täten.” Und tatsächlich ist da etwas dran!

Im Business-Alltag herrscht die analytische Denkform. Wenn es aber darum geht neue Lösungen zu finden, ist es ratsam, auch in andere Denkformen vorzustoßen. In unseren Design-Thinking-Trainings für Product Owner und ScrumMaster wird beispielsweise die Ideenfindung vom Mittagessen unterbrochen: Die Teilnehmer haben sich 30 Minuten intensivem Brainstorming hingegeben, ihr analytisches Denken hat die meisten Ideen und Lösungsmöglichkeiten bereits hervorgebracht, diese warten auf bunten Haftnotizen an der Wand. Der Strom der Ideen versiegt langsam. – Pause -

Wir schalten die analytische Denkform absichtlich ab, aber Sie können sicher sein, dass die Gedanken im “Hinterkopf” weiter kreisen. Gemeinsam oder auch einzeln gehen wir essen und die Bedingung ist, dass jeder einen Block Haftnotizen und einen Stift in der Tasche hat. Und nun passiert Erstaunliches: Die Teilnehmer haben die Gelegenheit, ihre Aufmerksamkeit in die Bereiche der Reflexion, der Inspiration oder auch des Loslassens gleiten zu lassen. Nach der Mittagspause beginnen wir mit einem Team-Resync, d.h. wir nehmen uns 15 Minuten Zeit, um neue Ideen und Einsichten zusammenzutragen. Erfahrungsgemäß bringt hier mindestens die Hälfte der Teilnehmer noch einmal sehr wertvolle Impulse in ihr Team: “Ich habe da draußen etwas gesehen, da habe ich mich erinnert, dass…” oder “als ich noch einmal in Ruhe darüber nachgedacht habe, habe ich gemerkt, wie wichtig mir dieser Aspekt ist” oder “ich habe gar nicht daran gedacht, aber plötzlich hatte ich die Idee …”.

Analyse, Inspiration, Reflexion & Loslassen

Werfen wir nun noch einen genaueren Blick auf diese vier Denkformen und betrachten wir das Two-by-Two Diagramm für die Aufmerksamkeit. Die horizontale Achse reicht von eng (links) bis weit (rechts), die vertikale Achse reicht von innen (unten) bis außen (oben). Damit ergeben sich vier Bereiche.

Design Thinking & Change Management Flipcharts

Aufmerksamkeit eng und nach außen gerichtet: Die Analyse

Hier bewegen wir uns i.d.R. im Business-Umfeld. Diese Denkweise ist anstrengend und wir halten das maximal 1,5 Stunden aus, danach sinkt unsere Leistungsfähigkeit rapide ab. Die Analyse ist geeignet, um sich initial mit einer Fragestellung zu befassen und ein Grundverständnis zu schaffen. Sucht man jedoch auf diese Art nach einer Lösung, wird man nur selten eine Innovation finden.

Aufmerksamkeit eng und nach innen gerichtet: Die Reflexion

In diesem Bereich bewegen wir uns, wenn wir über unsere Prioritäten und persönlichen Ziele nachdenken, wir zapfe unser Wissen und unsere Erfahrung an. Dieser Bereich ist wertvoll, um beispielsweise allein einen Stapel generierter Ideen zu bewerten und diese Ergebnisse später mit anderen zu teilen.

Aufmerksamkeit weit und nach außen gerichtet: Die Inspiration

Hier bewegen wir uns seltener, denn nun kommen unsere Vorstellungskraft und die Erlebniswelten anderer Menschen ins Spiel. Die Business-Welt hat Angst vor diesem Bereich, weil er nicht berechenbar und planbar ist. Viele Kreativtechniken probieren hier in den Raum des Denkbaren vorzustoßen. Gelegentlich müssen diese Vorstöße ganz sanft passieren, weil sich viele Menschen auf für sie unsicheres Terrain begeben. Ein Besuch beim User führt beispielsweise Software-Entwickler oder Ingenieure in den Bereich der Inspiration: “Nur mal ganz kurz … wir kehren gleich zurück … nur mal ganz kurz raus, da hin wo der User ist … nur mal ganz kurz nicht an die Machbarkeit denken … und dann hopp, hopp, schnell zurück.” Es ist immer wieder erstaunlich, wie viele Einsichten und Ideen von solchen Ausflügen mitgebracht werden.
Eine andere, noch komfortablere Methode, um in den Raum des Denkbaren zu gelangen, ist die Verlagerung der Frage an andere Orte oder Zeiten: “Wie würde Supermann das lösen? Wie würde das auf der Enterprise oder im Mittelalter aussehen?”

Aufmerksamkeit weit und nach innen gerichtet: Das Loslassen

Dies ist ein defokussierter Zustand, hier werden Metaphern und Witze verstanden. Es ist ein Bereich, der meist komplett ignoriert wird. Wer ihn allerdings entdeckt, kann beobachten, wie sich Lösungen ganz von selbst im Kopf materialisieren – meistens dann, wenn man es eigentlich gar nicht erwartet. Mancher Mensch kann diesen Zustand nach jahrelangen Meditationsübungen schnell herbeiführen. Mir gelingt es manchmal nach dem Sport unter der Dusche, wenn der Körper ermattet dasteht, Wasser über meinen Kopf fließt und meine Gedanken mit dem Wasser treiben. Gelegentlich “erwache” ich aus diesem Zustand und habe das dringende Gefühl, eine Art “Eingebung” aufschreiben zu müssen.

Integration ins Unternehmen

In Unternehmen ist es i.d.R. nicht einfach, den analytischen Bereich zu verlassen. Andere Denkweisen zu erkunden braucht Zeit und Raum! Außerdem vereinheitlicht die Unternehmenskultur die Denkweise von Mitarbeitern. Tradition und Gewohnheit verhindern den Blick über den Tellerrand. Und genau deshalb sind “Kreative” auch oft gerade dann produktiv, wenn man es ihnen nicht ansieht. Denn Sie haben Wege gefunden, sich mit Ruhe den anderen Denkweisen hinzugeben.

In der Innovationsarbeit gilt also:
Raus aus der Routine -> Sondersituation schaffen -> Rückführung in den Alltag

Dieser Prozess braucht eine professionelle Begleitung. Eine schnelle und günstige Lösung sind daher Coaches von außen, zumal Innovation auch immer eine Schleuse von außen nach innen benötigt. Aber auch die Schnittstellen in dieser Kette sind kritisch. Die Überführung von Wissen benötigt eine interne Konstante. Diese Konstante ist im besten Fall der Product Owner.

Tipp: Mit den unterschiedlichen Arten der Aufmerksamkeit können Sie in unserem Training “Produktfindung mit Design Thinking” experimentieren. Alle Informationen und Termine gibt es hier.

Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?
Design Thinking für Product Owner – Teil 2: Das Design-Thinking-Team
Design Thinking für Product Owner – Teil 3: Des Design-Thinking-Raum
Design Thinking für Product Owner – Teil 4: Der Design-Thinking-Prozess

Related posts:

  1. Produktfindung mit Design Thinking
  2. Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?
  3. Design Thinking für Product Owner – Teil 2: Das Design-Thinking-Team

Categories: Blogs

Hungarian Notation for Teams

Agile Tools - Mon, 10/13/2014 - 07:04

SONY DSC

Back in the day when I was writing windows programs there was this thing called hungarian notation. It was a form of shorthand that allowed you to add the type of a variable to the name of the variable. It led to variable names like “lpszUserName” that stood for “long pointer to a zero terminated string named UserName.” It made for some pretty awkward variable names, but the idea was that you could always tell the type of the variable, even if you couldn’t see the declaration. It was kind of handy, at least until somebody changed the variable type and forgot to change the name. In hindsight, it really was always doomed to fail for almost any kind of legacy code. Name the variable wrong and you introduce subtle bugs that will haunt you for years.

So there we are looking at a list of teams the other day. They had a lot of interesting things in common. They all have some specialization in a given domain. Often they had different geographic location. We were wondering if perhaps they should have some sort of naming convention applied to their names. That’s when I perked up and said, “Hungarian notation for teams!” If the team is located in Bellevue, then we will use ‘bv’. If the team is in the mobile domain, we’ll use ‘mb’. So for a team named “Viper” located in Bellevue doing mobile development we would have “bvmbViper!” Maybe you have a team that is located in San Francisco ‘sf’ that works on web apps ‘wa’ called “Cheetah” we would have “sfwaCheetah.” Now you can simply look at the name of your team and know instantly where they work, and what they work on.

Genius! Maybe we should do this for people too? I’m an Agile manager ‘am’ who writes a blog ‘bl’. You can call me “amblTomPerry”


Filed under: Agile, Humor Tagged: hungarian notiation, name, notation, Teams
Categories: Blogs

Building the Agile Culture you want

When some organizations think of going Agile, they tend to gravitate toward applying a set of Agile practices.  While this provides insight into the mechanical elements of agile, these types of implementations tend to overlook the cultural elements.  A move to Agile implies that you make the cultural transformation to embrace the Agile values and principles and put them into action. 
Adapting an organization's culture is effectively an effort in change management.  And changing a culture is hard. People underestimate the difficulties of a culture change within their organization because it involves the cooperation of everyone. This is why some organizations avoid this.  But the business benefits can be tremendous. I have seen Agile efforts get started with poorly stated objectives and motivations, a lack of employee ownership or engagement, and a lack of thinking through the effort. Also, Agile journeys significantly benefit from education in both change management and agile techniques to achieve a meaningful cultural change. I have seen companies assign a member of senior management as the change agent, yet they have neither education nor experience in change management. A better approach may be to hire an Agile Coach with change management and Agile experience.
Creating or adapting a culture is not done by accident. It must be considered a change initiative and thought through. As part of readiness of deploying Agile, start the process of adapting to an Agile mindset and the culture you are looking for. What are some activities that will help you move to an agile culture?  Some include:
  • Recognizing that moving to Agile is a cultural change (it’s a journey)
  • Sharing and embracing the Agile values and principles (seriously folks!)
  • Moving to an end-to-end view of delivering value (don’t stop at just the build portion)
  • Adapting your governance to focus on value (enough with the cost, schedule, and scope!)
  • Evaluating employee willingness (employees are your brainpower!)
  • Gaining continuous feedback from customers (adapt toward customer value)
  • Adapting the reward system to align with the new culture (toward team and value)
  • Assessing executive support (build engagement along the way)

What other activities would benefit you in getting to an Agile culture?  Ultimately you want to start living the values and principles that help you develop the culture you are looking for.  As you have approached Agile in the past, how much of it was focused on the mechanics and how much was focused on adapting to an Agile culture? 

PS - to read more about really making the shift toward an Agile culture, consider reading the Agile book entitled Being Agile.  
Categories: Blogs

correction: Agile HARDWARE ....

Agile Scotland - Sun, 10/12/2014 - 20:08
I forgot the word HARDWARE in the last email.  I'm losing it ...

Great news! Agile Engineering expert, Nancy Van Schooenderwoert is over in Scotland again and is giving a seminar on the evening of the 30th of October on Agile Engineering. It's at Glasgow Caledonian University.
http://www.eventbrite.co.uk/e/agilescotland-agile-hardware-development-tickets-13660303335?utm_campaign=new_eventv2&utm_medium=email&utm_source=eb_email&utm_term=eventname_text

Clarke
Categories: Communities

[AgileScotland] Agile Engineering seminar - Glasgow Caledonian University - 30th October, start 7pm

Agile Scotland - Sun, 10/12/2014 - 20:00
Great news! Agile Engineering expert, Nancy Van Schooenderwoert is over in Scotland again and is giving a seminar on the evening of the 30th of October on Agile Engineering. It's at Glasgow Caledonian University.
http://www.eventbrite.co.uk/e/agilescotland-agile-hardware-development-tickets-13660303335?utm_campaign=new_eventv2&utm_medium=email&utm_source=eb_email&utm_term=eventname_text

Clarke
Categories: Communities

Building Glass Houses: Creating the Transparent Organization

Agile Tools - Sun, 10/12/2014 - 07:54

blur-city-drops-of-water-871-733x550

Visual management occurs at many levels. There is personal transparency: the ability for people to see what you are working on within the team. Then there is team transparency: the ability for stakeholders and other teams to see what the team is working on. Finally, there is organizational transparency: the ability for people within and outside the organization to see what the organization is working on. Ideally, we have all three levels of transparency fully developed in an Agile organization.

Individual transparency consists of the ways in which we communicate the state of our work to the team. We can use both active and passive mechanisms to achieve this. Active mechanisms are things like using one-way broadcast like yammer, or just shouting out when you need help, achieve victory, or otherwise want to share with the team. Then there is two-way broadcast like the status in the daily standup, one-on-one communication, working meetings like the planning and demo. Passive mechanisms include updating things like task boards, wiki pages, and status reports. All of this information is primarily directed at the team.

At the team level there are active and passive mechanisms for communication. There are burn down charts, task boards, calendars, which are all passive. Then there is the active communication that takes place at the scrum of scrums and other larger forums where multiple teams and stakeholders meet. I’ve often seen teams struggle to get information out at this level. They tend to do really well at the individual level, but at the team level it is not uncommon to find that teams aren’t getting enough information out beyond their own boundaries.

Finally at the organizational level there are active and passive mechanisms for communication as well. There are passive communication mechanisms like annual reports, company web pages, intranets, and billboards in the coffee room. There is also active communication at company meetings, and…often not much else. This is an area where as Agilists we need the most improvement. It seems as though the communication demands get more challenging the higher up the organization that you go.


Filed under: Agile, Coaching, Lean, Process Tagged: information radiators, transparency
Categories: Blogs

Selling Agile Contracts Slides from Agile Philly 1/2 Day Event 10/6/2014

Agile Philly - Sun, 10/12/2014 - 04:30

Hi All.

Noticed that the Dropbox link to my preso in the mail John circulated was broken so...

I renamed the preso to remove spaces, posted the thing on slide share, and create a tiny URL so you can get to it easy!

Enjoy: http://tinyurl.com/agile-contracts

I really enjoyed sharing this with the group. Please do not hesitate to contact me if you have questions or just want to discuss. I am definitely…

Categories: Communities

Knowledge Sharing


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