Skip to content

Feed aggregator

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 <em>well-formed outcome</em> 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

The Trap of Enterprise Requirements

Agile Artisans - Tue, 01/27/2015 - 02:00

The path of a requirement in a large organization is often foreign to those more familiar with small or medium companies. In smaller arenas, developers and testers help define requirements. Everyone has a clear view of what's being built because they had a hand in defining and refining the ideas. Do you have a question about what this feature should be or what this report should have? Go ask Mike or Sue. It was their idea.

Enterprise scale is different. When the program budget is half a billion dollars and there are a few thousand developers and testers involved, requirements are shifted to a specialized team. Often an entire division is tasked with searching out and documenting requirements. These requirements are compressed and converted into documents that can be shared with teams of developers to implement, and teams of testers to verify. Each team can become specialists and do their own job at peak efficiency. Unfortunately for most enterprises, this model doesn't work well.

Categories: Companies

Agile is NOT For You

Agile Management Blog - VersionOne - Mon, 01/26/2015 - 21:52

22135079_xl

Guest post from Daniel Gullo, Apple Brook Consulting

You are talking with two consultants about how to transform your organization into an Agile development company so that you can go faster and keep ahead of your competitors.

You explain to them that your stakeholders have a need to know what is going on and to that end, there are reports that need to be created. Furthermore, your product is governed by Sarbanes-Oxley controls, which absolutely MUST be followed. Funding for your projects is allocated two to three years in advance and is based on detailed estimates, which are in turn derived from the Work Breakdown Structure (WBS) for the project. None of this can change.

You continue to explain that the teams are geographically distributed across four continents and 10 time zones and that restructuring the teams and bringing the teams together, even just for release planning is not possible. Your organization also has no budget to buy things like webcams, additional monitors, team rooms, or even open wall space.

The ScrumMaster in your organization will be “in charge” of 10 to 15 teams and may have other responsibilities as well. Also, the “Product Owner” is really in charge of an entire business unit and won’t be writing any User Stories, so the business analysts will need to be a “Product Owner Proxy” for each team.

After spending 20 minutes relating all of this (and more) to the consultants, including how none of this is negotiable, you ask, “So, what are your thoughts on the best way to implement Agile development here?”

There is silence.

After what seems like an eternity, one of the consultants clears his throat and says “Agile development is NOT for you.”

Did you really just hear that??? Doesn’t this guy get it? Is he really so independently wealthy that he is going to throw away the money that is on the table??

There’s a saying that goes: “If you didn’t get the joke, then the joke was not for you.”

If your company is not open to change or trying new things or running experiments in order to learn, then, Agile is NOT for you.

If your organization is not interested in having happy employees by focusing on people or they aren’t willing to make an investment in tools or to look at simple measurements of customer satisfaction such as the Happiness metric or Net Promoter Score, then, Agile is NOT for you.

If you are not willing to explore what “possible” really means and thus, have an open mind to doing the unconventional, then, Agile is NOT for you.

I’m sorry. I really am.

Agile is not magic. We can’t produce something from nothing or make other trade-offs go away. In order to get X, then you must do Y. You can’t expect to maintain the status quo AND improve. It’s simply not the “real world.”

Agile is all about embracing the uncertainty of change and learning how to use it to your advantage.

As a consultant, I often test the waters a bit when going through the discovery stage with a new client. I might say something that represents a “worst case” scenario to see if they are prepared to go there if it comes to that. I also ask a lot of questions around seeing how they think about people, constraints, etc.

My educational background was in Law. I am inclined to look at possibilities. I often find myself in a workshop or training session orating as if I were in court:

“In your expert opinion as a Senior Software Developer, is it POSSIBLE that you could build production-ready features, albeit very small slivers, that are capable of functioning from end to end by cutting through the entire architecture?”

“No. We can’t produce anything of value in less than six weeks.”

“So, it’s NOT POSSIBLE to release a single field on a webpage with a submit button that applies some business logic and then inserts a value into a table in a database that only includes that field? That’s absolutely NOT POSSIBLE??”

“Um, well, yes.”

“I rest my case, your honor.”

Becoming Agile means being open to possibilities and options.

In a sense, BEING Agile is like acknowledging and understanding what innovation truly means in the same sense that an artist understands what “creativity” means. Is someone who simply slaps paint on a canvas with no understanding of what they are doing considered an “artist?” Most of us would say that they are not.

Likewise, I can explain the agile values, principles, practices, and dynamics of agile culture to someone, but I can’t tell them how to be innovative. That’s something that has to come from within.

It’s uncomfortable, change.

And, through discomfort, we learn and grow.

If you are comfortable with how everything is going, then you aren’t learning.

If you aren’t comfortable with the prospect that Agile is going to make you uncomfortable, then sorry; Agile is NOT for you…

Categories: Companies

5 Common Pitfalls for a Product Owner

Illustrated Agile - Len Lagestee - Mon, 01/26/2015 - 21:00

The role of product owner is both a rewarding and challenging experience as those who are currently functioning in the role can probably attest to. There are highs and lows but the opportunity to shape and influence a product vision and see it come to life is a gratifying experience for most.

Over time, however, even the best of product owners can become susceptible to a few pitfalls keeping them from building products people love or allowing themselves to burn-out. During the past couple years of observing and coaching product owners, I have captured five of the most common traps unwary product owners can fall into:

Visioning in Isolation. There may be blind-spots with the assumptions you are making and experiments you are trying during product visioning if your vision is created without the insight of others.

  • Leverage actual users. Find a way to gain empathy with the people who will be paying for or using your product. Assuming or guessing what your customers need is a sure way to waste the investment made in you and your team.
  • Leverage others on the discovery team. As mentioned in this post, a product vision become out-of-balance without the perspectives of value, usability, and feasibility.
  • Leverage the delivery team. Ask for and listen to the ideas of the team about where they think the product should go.
  • Leverage leaders and stakeholders. Continuously seek to intertwine the enterprise vision with your product vision and learn the impact new features will have on your stakeholders.
  • Leverage colleagues. Share visionary ideas with other product owners and trusted friends. Build and commit to a community of practice.

Disconnecting from Delivery. It is often easy to get lost in visioning and lose touch with the execution of your vision.

  • Dedicate yourself to team ceremonies. Make the commitment to attending the 4 primary team sessions (planning, daily standup, review, and retrospective if you are using Scrum). Move any other meeting request overlapping this time…you need to be with your team.
  • Be visible and accessible. Beyond normal team sessions throughout a sprint, maintain a presence with the team. This will allow you to answer on-the-fly questions, provide immediate feedback, quickly remove impediments, and (most importantly) connect with the team by “participating” in any team fun, hijinks, and adventure. Yes, this really did happen to me…

Planning with Fixed Dates. Product owners often receive feature requests/demands with mandated fixed delivery dates as well. I call this being a product “renter” as this doesn’t feel much like “ownership.” Of all the things frustrating a product owner, this would probably be at the top of the list.

  • Through early conversations, communicate and negotiate with the requestor to adjust scope or time based on the historical velocity of the team. Continuing to say “yes” to these requests will reinforce the dysfunction of committing to dates without understanding scope and will escalate the frustration of the team. Coordinate with the Scrum Master to help if necessary.
  • Use your interactions with leaders and stakeholders wisely. Begin to educate them on the benefits of small features and minimum viable increments.

Not Measuring Impact. Many product owners have a hard time quantifying the impact new features are having in the market. This often results in a scattered “try anything” approach to product development instead of a laser-focus on solving specific needs.

  • Study The Lean Startup by Eric Ries, if you haven’t already. Understanding the key metrics and what is “moving the needle” is crucial to the success of your product.
  • Revise and adapt what is being measured as the product vision changes. What was important in the past may not be important today.

Losing Passion. The product owner is a high pressure and stressful gig, often requiring long hours and dedication. I have seen many product owners burn-out and begin to lose focus.

  • Take care of yourself. Whatever this means for you (exercise, vacation, family, friends, meditation), allocate time in the schedule for yourself.
  • Get out of the office. Re-connect with your customers (or users) by heading out to where they are. Spend a whole day with them. Go out to lunch and have a conversation about what they are experiencing. Observing their struggles may be just what you need to regain your momentum.
Becoming a Catalyst - Scrum Master Edition

The post 5 Common Pitfalls for a Product Owner appeared first on Illustrated Agile.

Categories: Blogs

Free Online Scrum Tools

Scrum Expert - Mon, 01/26/2015 - 18:11
Agile approaches like Scrum recommend a “just enough” attitude in software development and this is also the case when you discuss tools. Ideally, you would work with a small team that is collocated, but this is not always possible and you might be running your project in a virtual mode with a distributed Scrum team scattered around the world. If you don’t want to start using a sophisticated tool to manage your efforts, you might be interested in adopting some web tools that will fit your particular need to share ...
Categories: Communities

Scrum @ Scale Online Course Postponed

Scrum Log Jeff Sutherland - Mon, 01/26/2015 - 17:13
Due to the forecasted blizzard in New England, we are closing the Scrum Inc. office. Tomorrow's free webinar on Scrum @ Scale is delayed until Wed. 2/4 at 11am EST. 

We want you to choose the backlog for our January online course on Scrum at Scale. Scrum Inc.’s CEO Jeff Sutherland will present an in-depth analysis of the modules most requested by attendees, as well as making plenty of time for Q&A. So be sure to enter your top three modules when you register. For a complete list of all modules, click on the info graphic to the right.

The Scrum at Scale framework allows for context-specific solutions to scaling, unlike other prescriptive methodologies. The modular architecture of the framework enables organizations to incrementally inspect and adapt their own structure without causing system-wide consequences.

Live broadcast: Tuesday, January 27th, at 11:00 Eastern

Length: 1 hour

Cost: Free

All of Scrum Inc.'s online courses are eligible for Project Management Institute PDUs and Scrum Alliance SEUs. For more on how to claim your PDUs and SEUs, visit our FAQ page.

The post Scrum @ Scale Online Course Postponed appeared first on Scrum Inc..

Categories: Blogs

Always use proper tool

tinyPM Team Blog - Mon, 01/26/2015 - 14:42

hammer
Photo Author: justinbaeder / photo on flickr

 

“A tool enhances our ability to achieve a certain effect (…). A hammer is good for sinking nails but a poor way to drive screws”
From Don Reinertsen’s “Managing the Design Factory”

 

There is no need to say how crucial it is to use proper tools in order to achieve specific results. Just like in above quote, we need to bear in mind that if we use a good – or rather, the best tool, it will “enhance our ability to achieve a certain effect”.

It’s not a rocket science but highly important rule. If you’re running a project you need to find the best tool that will help you to manage your projects efficiently. It’s also important that ‘the best tool’ that you’ve found should be as simply in use as possible. You don’t want to waste your time to understand how this tools works. Do you? Instead, you want to use it here and now!

That’s why we’ve created tinyPM – simply, intuitive and smart agile collaboration tool.
Here you can find a sneak peak to some great features:

 

Backlog
A place where you product vision takes shape. TinyPM not only lets you create your backlog but what is more important, it allows you to groom it. Reorder your stories with drag and drop, sort them, filter. Quickly tag many stories, change their colors. Edit story details through in-line editable fields.

 

Taskboard
It is a place closest to a white board on your wall. This is where things get done on a daily basis. You can shape your flow as you like, starting with the three default states we give you. Feel free to add more and take control over your board!
It’s up to you! Move them around, leave comments, assign as many team members as you like. This is a place where developers rule and we make sure to help them do things fast.

 

User stories
tinyPM gives you more than just a post-it note to write on. Swarm over user story, discuss it, attach details, tag it (if it’s hard to split product into a hierarchical structure, give it more dimensions), use different card colors and feel the power of visual management.

 

Customizable view
Different job may require looking at your data in a different way. When you start your project and plan ahead the things look different than when you are in the middle of your work. We understand that and provide you with customizable view options. Choose between cards and tables, change zoom level to hide or show more details. Switch between 1-column and 2-columns view whenever you need.

 

In order to get all of tinyPM awesome features go to:

http://www.tinypm.com/features

Categories: Companies

Scrum Alone is Not Enough

Notes from a Tool User - Mark Levison - Mon, 01/26/2015 - 09:11

Scrum Alone Is Not Enough

To be successful with Scrum in the long term you need more than the basic framework. This is intentional. Scrum provides the structure as a starting point, but it’s designed to work well when applied with other effective patterns.

Like the Design Patterns movement of the late ’90s, a pattern can be used by itself or with others. E.g. the Command Pattern and the Memento Pattern can be combined to build an effective undo/redo system. Scrum is only one pattern for one team. It gives you the bare minimum framework that could possibly work, however in many contexts you will need to incorporate other tools/patterns to build more effective systems.

Beyond Scrum you should consider:

–       Effective Agile Engineering Practices – such as Unit Testing, Continuous Integration, Test Driven Development, Acceptance Test Driven Development (or BDD), Pair Programming. Without practices like these, the health of your codebase will degrade over time.

–       Kanban – (a tool to understand and improve flow) to help understand the flow of work at both the team and organization level. Without a good understanding of flow of work through the organization, we might make a change that is a local improvement but harms the whole.

–       Portfolio Management – the art of making big picture decisions about which major chunks of work the business would like focused on next. Organizations need portfolio management to ensure that major priorities are understood by the team’s Product Owners and worked on in priority order.

–       Organizational Improvement – many issues that Scrum helps to find can’t be solved by the team or their ScrumMaster. Instead, organizations need to establish an ongoing improvement team dedicated to resolving these problems.

–       Intra Team Coordination – How will you coordinate the work among teams? Scrum of Scrums is the most well known pattern and yet is rarely the best choice.

–       Team Organization – How will you organize your teams? As Component Teams? As Feature Teams? Using the Spotify model of Squads, Tribes and Guilds?

There are no best practices.

Scrum itself could prescribe all of this, but that would be missing an important Agile point: there are no best practices. A practice that works well in one organization (or context) may not work well in yours.  This is especially true when it comes to working effectively at a large scale where repeatable patterns are only just starting to emerge. Even where consistent patterns are starting to emerge (i.e. Large Scale Scrum, Enterprise Scrum, …), it is often unclear which one will apply in a specific context.

Finally, remember that Scrum isn’t intended to fit your current organization and its existing structure. It is intended to force us to consider what is working and what needs improvement.

Scrum is just the starting point.

 

In the next few months, I will explore patterns that can be effective when attempting Scrum at a larger scale (more than three teams). What topics would you like me to explore?

Categories: Blogs

Servant Leader: Agile Führungskraft oder ein Kleinstbeitrag zu einer besseren Welt?

Scrum 4 You - Mon, 01/26/2015 - 08:55

Mit dem Trend zur „Agilität“ hat ein neuer Begriff Einzug in deutsche Unternehmen gehalten: jener des „Servant Leader“. Ein Begriff, der ursprünglich von Robert K. Greenleaf, dem Gründer des Greenleaf Center for Servant Leadership, geprägt wurde. Was hat es damit auf sich? Was ist ein Servant Leader? Was macht ihn dazu? Eines scheint aus der Literatur schnell klar zu werden: Vieles von dem, was wir einmal über Führung, Zucht und Ordnung gelernt haben, scheint dadurch ganz und gar in Frage gestellt. Schauen wir auf die deutsche Bedeutung der Worte: „Servant“ steht für „dienend“. „Leader“ steht für „Führer“. Ein dienender Führer? Wie geht das zusammen? Ganz einfach. Servant Leader kann man nur sein, man wird es nicht durch eine Beförderung.

Sein statt Schein

Der Servant Leader handelt nicht so, wie er es eben tut, weil er dafür Anerkennung, Geld oder Status erlangen möchte. Er tut es um des Tuns Willen. Er streift diese Eigenschaft nicht morgens um 09:00 Uhr im Büro über und legt sie abends wieder ab, bevor er nachhause geht. Er verhält sich beruflich wie privat völlig natürlich. Der Servant Leader würde sein Verhalten selbst auch nicht als Führung bezeichnen. Er führt ohne durch Position oder Titel verliehene Macht – so etwas gibt ihm nicht viel. Das Bedürfnis, seinen Mitmenschen zu dienen und etwas Sinnvolles zu tun, liegt ihm im Blut. So zu sein ist für ihn keine Anstrengung oder ein Akt der Selbstverleugnung. Betrachten wir nun das Wort „dienen“ in seiner eigentlichen Bedeutung laut Duden, dann geht es darum, sich freiwillig seinen Mitmenschen oder einer Sache unterzuordnen. Ganz im Stile eines Gastgebers: Er sorgt für seine Gäste, ordnet sich ihnen freiwillig unter, bestimmt gleichzeitig aber auch den Rahmen und die Regeln. Denn es ist ja seine Veranstaltung. Haben Sie die Kollegen schon einmal als Ihre Gäste gesehen? Sollten sich gerade Gegenargumente in Ihr Bewusstsein drängen, bedenken Sie eines: Sie sind die Führungskraft. Es ist Ihre Aufgabe, den ersten Schritt zu gehen. Sie sind das – positive oder negative – Vorbild, ob Sie wollen oder nicht. Sie haben keine Wahl. Aber Sie haben die Wahl, welches Vorbild Sie sein wollen. Es wird Ihnen schon kein Zacken aus der schwer erarbeiteten Krone brechen – es ist einen Versuch wert.

Servant Leader schaffen Sicherheit

Was dann geschieht, ist nämlich hochinteressant: Sorgt ein Servant Leader für seine Mitmenschen und schafft Vertrauen, so entsteht Sicherheit. In unserer nach wie vor von den Spätfolgen der Weltkriege und aktuellen Konflikte geprägten westlichen Welt ist Sicherheit ein starkes Grundbedürfnis. Wer es schafft, Sicherheit herzustellen, findet eine Anhängerschaft. Im Kontext der Arbeitswelt folgen die Mitarbeiter dem Servant Leader also, weil sie es wollen, nicht weil sie es müssen. Er tut alles für sie, sie tun alles für ihn. Mitarbeiter werden Fans ihres Unternehmens. Einer der deutschen Rudermeister von 1984 sagte mal zu mir: „Wir holten den Titel für unseren Trainer, wir wären für ihn bis zur Bewusstlosigkeit gefahren.“ Als ich ihn fragte warum, antwortete er: „Weil der Trainer alles für uns getan hat.”

Vielleicht haben Sie den Film „Patch Adams“ gesehen. Er basiert auf der Lebensgeschichte des amerikanischen Arztes Dr. Patch Adams, der als begeisterter Querdenker seine Ausbildung aufs Spiel setzte. Er versuchte, mit Hilfe von Clowns ein Lachen in die Krankenzimmer amerikanischer Spitäler zu bringen – er war davon überzeugt, dass Humor die Heilung unterstützt. Er war bereit, sich seiner Idee völlig unterzuordnen, auch wenn er zunächst von der klassischen Schulmedizin dafür angefeindet wurde. Aus dieser Haltung heraus und ohne jede bewusst gewählte Anstrengung scharte er eine große Anhängerschaft um sich und darf heute das „Gesundheit! Institute“ sein Lebenswerk nennen. Patch Adams und seine Mitarbeiter versuchen Spitäler zu schaffen, in denen wieder das Wohl des Menschen – sowohl als Patient als auch als medizinischer Mitarbeiter – über allen geschäftlichen Interessen steht. Das inkludiert die kostenlose Behandlung mittelloser Menschen.

Menschen suchen Sinn

Patch Adams ist also jemand, der in erster Linie wohltätig handelt. Doch unsere Geschäftswelt besteht nicht aus Wohltätigkeit. Muss das so sein? Die gesellschaftliche Entwicklung bietet uns eine große Chance: Viele Menschen von heute, die in großem Wohlstand aufgewachsen sind, suchen nach wirklichem Sinn in ihrem Leben. Und das tun sie natürlich auch in der Arbeit, die nun mal einen großen Teil der Lebenszeit beansprucht. Menschen, die nach Sinn streben, möchten eine ebenso sinn-hafte und sinn-volle Führung durch eine von ihnen selbst erwählte Person erleben und eher einer Vision folgen, als die Befehle eines lediglich durch Hierarchiestufen legitimierten „Vor die Nase Gesetzten“ abzuarbeiten. Mittlerweile werden übrigens in immer mehr Unternehmen die Führungskräfte tatsächlich gewählt. Ganz demokratisch, so wie in der Schule die Klassensprecher gewählt werden.

Der Servant Leader ist – noch – eine idealisierte Figur. Vielleicht ist er das aber nur, weil wir ihn noch so selten antreffen? Abschließend möchte ich Ihnen zwei Fragen stellen.

  1. Hätten Sie etwas dagegen gehabt, wenn Mutter Theresa einen zweistelligen Millionenbetrag als Jahresgehalt erhalten hätte?
  2. Erinnern Sie sich noch an diesen einen Lehrer oder diese eine Lehrerin? Sie waren immer gerne in dieser Unterrichtsstunde, weil er oder sie die Schülerinnen und Schüler begeistern konnte und gefördert hat, obwohl andere vielleicht kein Potenzial gesehen haben. Der eine Lehrer, der nach dem Unterricht noch etwas länger geblieben ist, um Ihnen noch ein zehntes Mal etwas zu erklären, das Sie noch nicht verstanden hatten. Der Lehrer, der Sie vielleicht auch ein wneig zu dem gemacht hat, was Sie heute sind. Wie war sein oder ihr Name?

Wenn ich diese Frage in ein paar Jahren den Menschen in Ihrem Unternehmen stelle: Wäre es nicht toll, wenn sich die Menschen an Ihren Namen erinnern? Sollten Sie jetzt auch nur den Hauch eines wohligen Gefühls wahrnehmen, sind Sie den ersten Schritt schon gegangen.

Categories: Blogs

Agile Success Measures for your Agile Transformation

I often get asked, “How do I know when my company is Agile? ” While I have various answers, it led me to construct an Agile measurement framework that helps you guide your Agile transformation toward success.      I start by asking, “What outcomes an organization would like to see when they go Agile?”  Agile asks that you consider your outcome instead of output as a measure of success.  I would suggest that being Agile should only occur if your outcome is some type of better business results.  In other words, Agile shouldn't be the outcome of being Agile.  The good news is that organizations are looking for better business results.  This could be in the form of shorter lead times, reduced whip, or an increase in revenue.  Sometimes it can be all three. It is important to understand that outcomes are lagging metrics.   Now that we have highlighted the importance of outcomes, let’s add two ingredients to give us perspective and help us build the framework.

For the first ingredient, I will take a page from the book Being Agile in Chapter 2 “Crossing the Agile Chasm”.  When we discuss Agile adoption, we are talking about a change to the organizational culture.  This is because adopting Agile is more than learning skills or understanding a procedure.  It is about adopting a set of values and principles that require change in people’s behavior and the culture of an organization.  This mindset and culture change involves the most time for an organization to adjust.  According to Paul S. Adler and Aaron Shenhar, “Adapting your Technological Base: The Organizational Challenge”, a culture change is measured in years.   
For the second ingredient, I will take a page out of the article Agile Lagging to Leading Metric Path.  This article highlights that an Agile lagging to leading metric path recommends that for every outcome (aka, lagging indicator), you supplement it with corresponding leading indicators that provide you with visibility during an Agile transformation.  Capturing the leading indicators helps you steer toward a successful Agile transformation.  The leading indicators are effectively feedback loops that help you understand if you are leading toward your outcome.
Now that we have the two key ingredients, the goal is constructing an Agile lagging to leading metric path that recognizes that change takes time and provides us with feedback to adapt toward a more successful Agile transformation.   Lets start with the outcome.  For my Agile transformation, the key outcome is that we are seeing better business results for our products, translated into increased revenue for our business.  From this, I need to consider what leading indicators help guide me toward better business results.   From my Agile transformation experience, I will suggest that the two broad leading indicators are adopting Agile mechanics and embracing the Agile mindset.   Here is an illustration of the suggested framework.
This illustrates several conventions.  The first is that from an Agile perspective, in order to get to better business results, we must educate folks on the Agile mechanics and Agile mindset.  As we do this, we gain feedback so that we can adapt the Agile journey to ensure a success Agile transformation and achieve the better business results we are looking for.  The second is that applying Agile mechanics tends to be easier and takes less time since it only involves learning skills and understanding procedures.  Adopting an Agile mindset takes more time since it requires changes in people’s behavior and the adaption of the organizational culture.  The end result (outcome or lagging metric) is that we hope to see better business results by first implementing Agile mechanics and adapting to an Agile mindset. 
The last task at hand is to create measures within each indicator to gauge progress.  For the Agile mechanics, capturing a training metric is helpful.  In order for people to mechanically adopt Agile, they need some form of education in their role (e.g., Scrum Master, Product Owner, etc.) and education in the procedure (e.g., Scrum, Kanban, etc.).  Then you can assess if the mechanics are being applied.  If education doesn’t occur or the mechanics aren’t be followed, how do you expect to do Agile? 

As for the Agile mindset indicator, you can assess if the Scrum Master is exemplifying servant leadership, you can gauge if management are allowing for self-organization, you can access if the team believes in the Agile values and principles, and you can determine if the product owner and organization are adapting to delivering early and often.  If the behaviors behind the Agile mindset are not occurring, how do you expect to be Agile?   This is why they are all leading indicators to getting better business results. 
I hope this article highlights helps you establish a framework to help you more effectively measure “How do we know when we are Agile?”.  Many end their journey with adopting Agile mechanics without adapting their culture toward an Agile mindset.  Stopping at the mechanics is why many organizations fail at Agile.  This article also highlights that if you are looking for the business benefits that Agile can bring, then establishing an Agile measurement framework based on lagging to leading indicators can help guide you achieve a more successful Agile transformation. 
Categories: Blogs

Python: Find the highest value in a group

Mark Needham - Sun, 01/25/2015 - 14:47

In my continued playing around with a How I met your mother data set I needed to find out the last episode that happened in a season so that I could use it in a chart I wanted to plot.

I had this CSV file containing each of the episodes:

$ head -n 10 data/import/episodes.csv
NumberOverall,NumberInSeason,Episode,Season,DateAired,Timestamp
1,1,/wiki/Pilot,1,"September 19, 2005",1127084400
2,2,/wiki/Purple_Giraffe,1,"September 26, 2005",1127689200
3,3,/wiki/Sweet_Taste_of_Liberty,1,"October 3, 2005",1128294000
4,4,/wiki/Return_of_the_Shirt,1,"October 10, 2005",1128898800
5,5,/wiki/Okay_Awesome,1,"October 17, 2005",1129503600
6,6,/wiki/Slutty_Pumpkin,1,"October 24, 2005",1130108400
7,7,/wiki/Matchmaker,1,"November 7, 2005",1131321600
8,8,/wiki/The_Duel,1,"November 14, 2005",1131926400
9,9,/wiki/Belly_Full_of_Turkey,1,"November 21, 2005",1132531200

I started out by parsing the CSV file into a dictionary of (seasons -> episode ids):

import csv
from collections import defaultdict
 
seasons = defaultdict(list)
with open("data/import/episodes.csv", "r") as episodesfile:
    reader = csv.reader(episodesfile, delimiter = ",")
    reader.next()
    for row in reader:
        seasons[int(row[3])].append(int(row[0]))
 
print seasons

which outputs the following:

$ python blog.py
defaultdict(<type 'list'>, {
  1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22], 
  2: [23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44], 
  3: [45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64], 
  4: [65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88], 
  5: [89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112], 
  6: [113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136], 
  7: [137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160], 
  8: [161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184], 
  9: [185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208]})

It’s reasonably easy to transform that into a dictionary of (season -> max episode id) with the following couple of lines:

for season, episode_ids in seasons.iteritems():
    seasons[season] = max(episode_ids)
 
>>> print seasons
defaultdict(<type 'list'>, {1: 22, 2: 44, 3: 64, 4: 88, 5: 112, 6: 136, 7: 160, 8: 184, 9: 208})

This works fine but it felt very much like a dplyr problem to me so I wanted to see whether I could write something cleaner using pandas.

I started out by capturing the seasons and episode ids in separate lists and then building up a DataFrame:

import pandas as pd
from pandas import DataFrame
 
seasons, episode_ids = [], []
with open("data/import/episodes.csv", "r") as episodesfile:
    reader = csv.reader(episodesfile, delimiter = ",")
    reader.next()
    for row in reader:
        seasons.append(int(row[3]))
        episode_ids.append(int(row[0]))
 
df = DataFrame.from_items([('Season', seasons), ('EpisodeId', episode_ids)])
 
>>> print df.groupby("Season").max()["EpisodeId"]
Season
1          22
2          44
3          64
4          88
5         112
6         136
7         160
8         184
9         208

Or we can simplify that and read the CSV file directly into a DataFrame:

df = pd.read_csv('data/import/episodes.csv', index_col=False, header=0)
 
>>> print df.groupby("Season").max()["NumberOverall"]
Season
1          22
2          44
3          64
4          88
5         112
6         136
7         160
8         184
9         208

Pretty neat. I need to get more into pandas.

Categories: Blogs

Organisation Structure in 3D?

Agilecraft - Petri Heiramo - Sat, 01/24/2015 - 03:23

The traditional way to show the hierarchy of a traditional organization is with the CEO at the top and the workgroups/teams at the bottom. The Toyota way (as far as I know) is to reverse it, with the CEO at the bottom. I don’t think either shows the diagram as I’d really like, although the reversed model feels much better to me.

The reason is, the CEO role is a dual role of support and showing direction. In the support role, the role is certainly “at the bottom”, providing support for everyone else in their jobs. In the showing direction role, it is at the tip of the organization.

I have often wondered how I could show that duality effectively, both at the same time. Tonight, as I was going to sleep, an image came to me. I had to get up and do it (and then blog it) so that I don’t forget it.

Here’s the image:

Organisation structure in 3D

It’s pretty rough picture since I had to do it quickly (still gotta get to bed before dawn breaks). But imagine that like a triangular arrowhead pointed towards better future. Read the diagram on the top and the back.

Certainly, that diagram is useful only in the context of more hierarchical organisations. Organizations like Futurice and Spotify are better described with other approaches.


Categories: Blogs

Knowledge Sharing


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