Skip to content

Feed aggregator

Storytelling for Brands

About SCRUM - Hamid Shojaee Axosoft - Tue, 02/17/2015 - 19:18

If it looks like marketing, acts like marketing, smells like marketing…it’s marketing! So, what’s a marketer to do?

This is the dilemma for all of us who are trying to tame the beast that is “content marketing.” How can we get people to engage with our brand, share our content, and maybe buy whatever the hell it is that we’re selling – without being salesy? This is counter-intuitive to a lot of traditional marketing best practices that I’ve learned. But wait a second…

I hate being sold to, yet I have an online shopping addiction. So how do brands convince us to buy? They tug at our heartstrings with videos of puppies. They captivate us with powerful moments captured by people just like us. They remind us that we can make an impact that is “Bigger Than Us.”

I love these brands because they appeal to me on an emotional level; I can relate to them, my beliefs align with theirs, and suddenly I care about all this amazing content they’re sharing with me. Simon Sinek’s TEDx Talk, How Great Leaders Inspire Action, really helped solidify this idea that people don’t buy what you do, they buy why you do it. The key is showing your customers what you believe in so that they can decide if it aligns with their beliefs.

Everyone in marketing can do this! It’s called storytelling. And the good news is that humans have been successfully telling stories since… forever! Seriously, like thousands of years ago we were carving narratives into the walls of caves and sitting around a campfire sharing stories. Shane Snow wrote a great article about storytelling as the top business skill of the next 5 years, in which he said, “now more than ever, businesses, workers, and leaders have opportunities to stand out, spread messages, and make change through storytelling”.

So in reality, how lucky are us marketers?! Instead of having to go old school and sell a product, we have the freedom to craft these really beautiful, funny, and honest stories that reflect our brands.

I hope you’ll subscribe to our newsletter and let the quirky personalities of Axosoft into your inbox each week to share our collective knowledge!*

*We reserve the right to share our stories in the form of novels, short stories, haikus, infographics, videos, or whatever else strikes our fancy!

Categories: Companies

Storytelling for Brands: Can Marketers be Eloquent Storytellers?

About SCRUM - Hamid Shojaee Axosoft - Tue, 02/17/2015 - 19:18

If it looks like marketing, acts like marketing, smells like marketing…it’s marketing! So, what’s a marketer to do?

This is the dilemma for all of us who are trying to tame the beast that is “content marketing.” How can we get people to engage with our brand, share our content, and maybe buy whatever the hell it is that we’re selling – without being salesy? This is counter-intuitive to a lot of traditional marketing best practices that I’ve learned. But wait a second…

I hate being sold to, yet I have an online shopping addiction. So how do brands convince us to buy? They tug at our heartstrings with videos of puppies. They captivate us with powerful moments captured by people just like us. They remind us that we can make an impact that is “Bigger Than Us.”

I love these brands because they appeal to me on an emotional level; I can relate to them, my beliefs align with theirs, and suddenly I care about all this amazing content they’re sharing with me. Simon Sinek’s TEDx Talk, How Great Leaders Inspire Action, really helped solidify this idea that people don’t buy what you do, they buy why you do it. The key is showing your customers what you believe in so that they can decide if it aligns with their beliefs.

Everyone in marketing can do this! It’s called storytelling. And the good news is that humans have been successfully telling stories since… forever! Seriously, like thousands of years ago we were carving narratives into the walls of caves and sitting around a campfire sharing stories. Shane Snow wrote a great article about storytelling as the top business skill of the next 5 years, in which he said, “now more than ever, businesses, workers, and leaders have opportunities to stand out, spread messages, and make change through storytelling”.

So in reality, how lucky are us marketers?! Instead of having to go old school and sell a product, we have the freedom to craft these really beautiful, funny, and honest stories that reflect our brands.

I hope you’ll subscribe to our newsletter and let the quirky personalities of Axosoft into your inbox each week to share our collective knowledge!*

*We reserve the right to share our stories in the form of novels, short stories, haikus, infographics, videos, or whatever else strikes our fancy!

Categories: Companies

Multiple Levels of Done

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

Having a “definition of done” has become a near-standard thing for Scrum teams. The definition of done (often called a “DoD”) establishes what must be true of each product backlog item for that item to be done.

A typical DoD would be something similar to:

  • The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
  • The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
  • The code was either pair programmed or peer reviewed.
  • The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
  • The feature the code implements has been documented in any end-user documentation such as manuals or help systems.

Many teams will improve their Definition of Done over time. For example, a team using the example above might not be able to do so much automated testing when first starting out. But, hopefully, they would add that to their definition of done over time.

All this is sufficient for the vast majority of teams. But I’ve worked on a few projects whose teams benefitted from having multiple definitions of done. A team takes a product backlog item to definition of done Level 1 in a first sprint, to definition of done Level 2 in a subsequent sprint, and so on.

I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels. Let’s look an example.

An Example from a Game Studio

One thing I’ve really enjoyed in working with game studios is that they understand that not all work will make it into the finished game. Sometimes, for example, a game team experiments with a new character trying to make the character fun. If they can’t, the character isn’t added to the game.

So it would be extremely wasteful for a game team to have a definition of done requiring all art to be perfect, all audio be recorded, and refresh rates be high when they are merely trying to decide if a new character is fun. The team should do just enough to answer that question.

In a number of game studios, this has led to a four-level definition of done:

Done, Level 1 (D1) means the new feature works and decisions can be made. For animation, this was often “the character is animated in a white room.” It’s “shippable” to friendly users (often internal) who can comment on whether the new functionality meets its objective.

D2: The thing is integrated into the game and users can play it / interact with it.

D3: The feature is truly shippable. It’s good enough to include in a major public release. The team may not want to release it yet—they may first want to improve the frame rate, add some polygons, brighten colors, and so on. But the feature could be shipped with this feature in this state if necessary.

D4: The feature is tuned, polished, and everyone loves it. There’s nothing the team would change. A typical public release will include a mix of D4 and D3 items. There will always be areas the team wants to go back to and further improve. But, time intrudes and they ship the product. So D3 is totally shippable. You’re not embarrassed by D3 and only your hardest core users will notice the ways it could be better. D4 rocks.

Are Multiple Definitions of Done Right for You?

Very likely not. Most teams do quite well with a single definition of done. But the ideas above extend beyond just game development. I’ve used the same approach in a variety of other application domains, notably hardware development. In that case, the teams involved were developing dozens of new gadgets for an integrated suite of home automation products.

They used these definitions:

D1: The new hardware works on a test bench in the office.

D2: The new hardware is integrated with the other products in the suite.

D3: The new hardware is installed and running in at least one model house used for this type of beta testing.

D4: The product is fully ready for sale (e.g., it meets all requirements for UL approval).

Within this company, there were dozens of components in development at all times, and some components could be found at each level of doneness. For example, a product to raise and lower window shades could be in testing at the model home, while a newer component to open and close doors had just been started and was only working on a test bench of one developer.

Most projects will never need this. If you do think it’s appropriate for you, before trying it, really be sure you’re not using the technique as an excuse to skip things like testing.

Each level should exist as a way of making decisions about the product. A good test of that is to see if some features are dropped at each level. It is a good sign, for example, that sometimes a feature reaches a certain doneness level, and the product owner decides the feature is no longer wanted due to perhaps its cost or delivery time.

Categories: Blogs

Should Agile Equal Being Happy?

Leading Agile - Tue, 02/17/2015 - 15:50

Ever had a conversation with someone about what they thought “being” Agile meant?  I was having that conversation today.  The other guy said he was surprised that he wasn’t happier.  I asked him to help me understand what he meant by that.

An Agile team should be happy

Someone, somewhere, convinced this fellow that the Manifesto for Agile Software Development included life, liberty, and the pursuit of happiness.

The reality is I feel he was misguided, just like all of those other people who think that if you’re on an Agile team then you don’t plan, you don’t test, or you don’t document. The ideas like Agile is all teddy bears and rainbows has somehow spread to the far reaches of the Agile community.

When asked if Agile makes me happy, my response was simple.

No

Being an Agile coach, leading Agile transformations, and helping customers reach their potential does not make me happy.  It leaves me with a feeling of satisfaction.  Much like mowing my lawn every weekend in summer, it doesn’t make me happy. But, when I am done with the task at hand, I look at what I have accomplished and I feel satisfied.  Isn’t that a more realistic goal? The pursuit of satisfaction, as it relates to work?  Happiness is an emotional state that I reserve to my personal life, when I combine satisfaction from my work and positive emotions in my off-time.

Is the goal of happiness within an Agile team misguided?

I’m interested in your thoughts.

The post Should Agile Equal Being Happy? appeared first on LeadingAgile.

Categories: Blogs

UPscALE Agile in Medium & Large Enterprises, Stuttgart, Germany, March 11 2015

Scrum Expert - Tue, 02/17/2015 - 11:25
UPscALE Agile in Medium & Large Enterprises is a one-day focused on the scaling of Scrum and other Agile software development approaches. All the talks are in German except of the keynote. In the agenda of UPscALE Agile in Medium & Large Enterprises you will find topics like the ” Scrum @ Scale – A Scaling Framework based on My Experiences” keynote delivered by Jeff Sutherland. The other presentations will be performed by medium and large enterprises like Volkswagen and SAP about their experience is scaling Agile. Web site: http://www.up-scale.de/ Location for the ...
Categories: Communities

Agile Misconceptions: There Is One Right Approach

Johanna Rothman - Mon, 02/16/2015 - 17:59

I have an article up on agileconnection.com called Common Misconceptions about Agile: There Is Only One Approach.

If you read my Design Your Agile Project series, you know I am a fan of determining what approach works when for your organization or project.

Please leave comments over there. Thanks!

Two notes:

  1. If you would like to write an article for agileconnection.com, I’m the technical editor. Send me your article and we can go from there.
  2. If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. Early bird pricing ends soon.
Categories: Blogs

What good are story points and velocity in Scrum?

Scrum Breakfast - Mon, 02/16/2015 - 12:10
We use velocity as a measure of how many story points to take into the next sprint. When you take in enough stories, and story points, so that you reach your average velocity, then, you can end the sprint planning meeting.Although this is a common approach, it is exactly how you should not use story points in Scrum. It leads to over-commitment and spillover (started, but unfinished work) at the end of the sprint. Both of these are bad for performance. How should you use story points in planning? How do you create the Forecast? And what do you do if the team runs out of work?

The first thing to remember is that Development Team is self-organizing. They have exclusive jurisdiction over how much work they take on. The Product Owner has final say over the ordering of items in the backlog, but nobody tells the the Development Team how much work to take on! Not the Product Owner, not the ScrumMaster, and certainly not the math!

As a Product Owner, I would use story points to help set medium and long-term expectations on what is really achievable. Wish and probable reality need to be more or less in sync with each other. If the disparity is too big, it's the Product Owner's job to fix the problem, and she has lots of options: less scope, simpler acceptance criteria, more time, more people, pivot, persevere, or even abandon.

As a ScrumMaster, I would use velocity to identify a number of dysfunctions. A wavy burndown chart is often a symptom of stories that are too big, excessive spillover, or poorly understood acceptance criteria (to name the most likely causes). A flattening burn-down chart is often a sign of technical debt. An accelerating burn-down chart may be sign of management pressure to perform (story point inflation). A lack of a burn-down or velocity chart may be a sign of flying blind!

As a member of the Development Team, I would use the estimate in story points to help decide whether stories are ready to take into the sprint. An individual story should represent on average 10% or less of the team's capacity.
How to create the Sprint ForecastHow much work should the team take on in a sprint? As Scrum Master, I would ask the team, can you do the first story? Can you do the first and the second? Can you do first, the second and the third? Keep asking until the team hesitates. As soon as they hesitate, stop. That is the forecast.

Why should you stop at this point? Taking on more stories will add congestion and slow down the team. Think of the highway at rush hour. Do more cars on the road mean the traffic moves faster? Would be nice.

Why do you even make a forecast? Some projects say, let's just get into a state of flow, and pull work as we are ready to take it. This can work too, but my own experience with that approach has been mixed. It is very easy to lose focus on getting things done and lose the ability to predict what can be done over a longer period of time. So I believe Sprint Forecasts are useful because they help us inspect-and-adapt enroute to our longer term goal.

What about "yesterday's weather"? Can we use the results of the last sprint to reality check the forecast for this sprint? Sure! If your team promised 100 but only delivered 70 or less, this is a sign that they should not commit to more than 70, and quite probably less. I call this "throttling", and it is one of my 12 Tips for Product Owners who want better performance from their Scrum Teams. But yesterday's weather is not a target, it's a sanity check. If it becomes your target, it may be holding you down.
What if the team runs out of work?On the one hand, this is easy. If the team runs out of work, they can just ask the Product Owner for more. A working agreement can streamline this process, for example, Team, if you run out of work, you can:

  • Take the top item from the product backlog.
  • Contact me (the Product Owner) if you get down to just one ready item in the backlog
  • Implement your top priority improvement to our code ("refactoring")

Implementing improvements from the last retrospective is usually a particularly good idea, unless you are very close to a release. There are investments in productivity that will often pay huge dividends, surprisingly quickly!


Categories: Blogs

What happen if you combine and integrate two awesome tools?

tinyPM Team Blog - Mon, 02/16/2015 - 11:17

tinypm_slack

Have you heard about Slack?
No? So you need to catch up. Slack is an awesome platform for team communication – “everything in one place, instantly searchable, available wherever you go“.

It’s really great! You can easily improve your team communication by creating open channels, projects and topics that the whole team shares. What we love the most in Slack?
- splendid search feature
- easy way to attach pictures and others
- beautiful design
- simplicity

It’s just “everything in one place”!

 

To provide you with essential value of your work
We’ve integrated tinyPM with Slack! Now you can check what happen when two awesome tools are working together to bring you everything that is necessary to do a great job!

This is one of these tiny things that help you to transform your good team into a great team! Now you can stay up to date with every change that was made in tinyPM. This integration will post updates to a channel in Slack whenever a story or task activity occurs. How cool is that? images

tinyPM_notification_in_Slack

That’s why we’ve decided to integrate our tinyPM with Slack – to provide you with essential value of being always aware of what’s going on with your projects. Getting notified about every change will helps you to manage your team and your projects more effeiciently.

 

How to connect your tinyPM with Slack?
It’s quite simple and intuitive. You just need to enable Slack integration with tinyPM just create an Incoming WebHook in your Slack:

  • Open Slack
  • Click on the dropdown next to your team name and select Configure integrations
  • Select Incoming WebHooks
  • Copy the Webhook URL to your clipboard

 

Once you create Incoming WebHook in Slack:

  • Open your tinyPM
  • Go to “Application Settings”
  • Click on Slack integration
  • Paste WebHook URL

 

That’s it! As simple as that. Now, working with tinyPM and Slack integration you will save your time, manage your projects way better that before and communicate more efficiently.

 

Tell us about your feelings with regards to tinyPM and Slack integration. We’re looking forward to receiving your feedback.

Categories: Companies

Early Bird Ends Soon for Influential Agile Leader

Johanna Rothman - Sun, 02/15/2015 - 22:46

If you are a leader for your agile efforts in your organization, you need to consider participating in The Influential Agile Leader. If you are working on how to transition to agile, how to talk about agile, how to help your peers, managers, or teams, you want to participate.

Gil Broza and I designed it to be experiential and interactive. We’re leading the workshop in San Francisco, Mar 31-Apr 1. We’ll be in London April 14-15.

The early bird pricing ends Feb 20.

People who participate see great results, especially when they bring peers/managers from their organization. Sign up now.

Categories: Blogs

Changing Behavior by Asking the Right Questions

George Dinwiddie’s blog - Sat, 02/14/2015 - 03:16

My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.

Categories: Blogs

The Fun Zone - The Sweet Spot Of Resilient Learning

LEGO SERIOUS PLAY TrainingWe all learn all the time, and we enjoy  it . Learning is exciting !  ... when we succeed .  Remember when you first learned to ride a bike ? Wan't it a little bit like a victory whet you first succeeded to make the bike move without someone discreetly holding your ? The big secret of learning with joy , though, is that we at, we don't play mental games like conceptualisation or arguing . Scientific research have shown that we exclusively learn from acting , never from listed concepts . To remember what we learned , the key sweet secret is to have fun during the learning process. Here is what we can do about it .
Let's  Go And Play !
We love challenges. Or don't we ? If you think a little bit , there are challenges that we enjoy and others that we fear and want to avoid . What is the difference ? You might say, ones are not important , others are crucial and may change your life.  Think of a challenge from the second category that you faced and had a good outcome ? How did you feel after ?
Now think of other "unimportant" challenges that you successfully solved? How did you feel after ?
What was the difference of emotions ? Relieved vs excited ? Powerful vs joyful ? Proud vs ... proud ?
At the end there is little ( no ) difference between the  emotional experience of overcoming a challenge of stake and  "superficial" little challenge.
If you were asked to name a type of "low stake challenge" experience, you probably name "playing games".
"Low stake" set-up is an interesting environment for learning, because we are in a safe zone "by design".  As we remember the rewarding feeling of solving a challenge ,  the best way to create resilient learning is to put ourselves in a "low stake" environment  to acquire desired skills. This environment is will be the "learning playground" . We are ready to play games to learn.

Good Games For Fun Learning
ATD2014 - Playing for the Next Demo Episode of
Our Killing AppDeciding to go play games is not  - at least not always - enough !  We enjoy playing a game because it is a good game. We learn effectively form a game when it is a goo ( learning ) game .
What is a good game ? Here is what games theory says about  good games :

  • Have  a goal ( an outcome to reach)
  • Have clear rules ( if not players won't know how to reach the outcome ) 
  • Give a sense of control of the game to the participants
  • Give a sense of progress in the game .


The Fun Zone Of  Learning
Comfort Zone For Learning
From the LSP Certification Training The sweet spot of  fun learning is the right balance between the level of difficulty of the challenge  in respect with the skills you have. Did you enjoy a game that was way too complex for you from the beginning ? Would you play a video game at level 7 when you never played it ?
But what about starting at level 1 and playing only level 1 over time ? Do you have the same "fun level" over time ? When we enhance our skills , we expect higher challenges. Because challenges that   are just over our skill level are the one that give us the best quality entertainment.
We have a sense of progress. We learned . We played together. And playing IS collaboration.

The graph of the "Learning Fun Zone" was presented by the Lego Serious Play Trainers during my Facilitation Certification Training. Credits to Jean Semo and Marie-Christine Dupont for it. 


Linked Materials :

JanetMcGonigal : Reality is Broken 
Categories: Blogs

Can You Mandate Your Agile Transformation?

Leading Agile - Fri, 02/13/2015 - 09:00

Well… it depends.

If you view agile as a system of beliefs, or a way of looking at the world, or as a culture your company is expected to adopt…I’d suggest that it’s impossible to mandate an agile transformation. There is no way to force people to believe in something they don’t believe in or to feel something they don’t feel.

If you view agile as a set of practices, or as a way of performing your day-to-day activities, or as a set of ceremonies and artifacts and roles that people are required to perform… I’d suggest that, while probably not impossible to mandate, at best you’ll get malicious compliance if you try.

If you view agile as a system of delivery predicated upon the notion of small cross-functional teams, and you mandate those teams have everything necessary to deliver a working, tested increment of the product… and you mandate the organization gives those teams extreme clarity around what you are asking them to build… and you mandate those teams deliver an increment of the product for inspection every couple of weeks, just so we can make sure they are on the right track, give them feedback, and validate they are making measurable progress against our business goals…

I’d suggest that it’s irresponsible NOT to mandate your agile transformation.

Once you mandate the right kind of agile transformation, now we can explore the wide palette of tools and techniques and practices that make that kind of system work, and we can invite the team to choose the tools and techniques and practices that work best for them in their particular context.

Once you mandate the right kind of agile transformation, and the team has everything they need to be successful, autonomy to make local decisions, and the safety to decide how to do the work and how much work can be done, you can then invite them to change their mind about what they believe.

Mandating an agile transformation and inviting people to participate are not mutually exclusive. We just have to be clear on what’s negotiable and what isn’t.

The post Can You Mandate Your Agile Transformation? appeared first on LeadingAgile.

Categories: Blogs

An open letter about unit tests

George Dinwiddie’s blog - Fri, 02/13/2015 - 04:33

An open letter to a programmer who thinks that code coverage by integration tests eliminates the need for unit tests.

Why do we want tests? Typically, we want functional or acceptance test to demonstrate that the system, as a whole, functions the way we (or “the business”) wants it to function. We want integration tests to demonstrate that the subsystems talk to each other properly, as often errors creep in with differing expectations at these major system boundaries. And we want unit or micro tests to demonstrate that the code works the way the programmer thinks it should work. This is the business view of tests.

From a personal point of view, as a programmer I want tests to make my life easier as a programmer. Tests, particularly unit tests, give me quick feedback when my changes to the code have violated previous expectations of the code. They let me know when I’ve accomplished the functionality that lead me to make changes. They let me reorganize the code without worrying about making a mistake, because the tests will immediately alert me if I do. They let me move quickly, because the tests can analyze the holes in my design much more quickly than I can. And they save me from lots of embarrassment that comes from delivering buggy code.

You might think that we only need one level of testing. As long as a line of code is covered by a test, why cover it again? In a perfect world, shouldn’t this be sufficient?

In a perfect world, we wouldn’t need to write tests at all. We’re not in a perfect world, and neither are our tests. Our functional tests can look at the whole system, but has a hard time exercising the edge conditions deep in the code. The fact that a line of code has been exercised by a test does not tell us that the line works properly under various conditions. Our unit tests can easily check the boundaries of a small piece of code, but can’t assure us that the pieces are connected together properly. We need multiple levels of testing to get the assurance we need.

In addition, tests have other attributes. Unit tests run much faster (much less than a second) than integration or functional tests. This lets us run them much more frequently (several times a minute) and quickly get feedback on the effect of our latest code change. They can also diagnose the errors much more precisely than larger scale tests. They can codify our assumptions about the way a piece of code works, so if someone else makes a change that breaks those assumptions it becomes immediately obvious. Done well, unit tests give us confidence to move fast and stay out of the debugger.

If you’re not getting these benefits from unit testing, call me and I’ll work with you on them. Life is too short to struggle with unit tests and not get the value they can offer.

Categories: Blogs

Some Thoughts on Self-Organization in Agile Teams

Leading Agile - Fri, 02/13/2015 - 01:04

I think some of us are getting it wrong when it comes to self-organization.

Self-organization doesn’t mean that the team doesn’t have managers or that they get to decide what problems to solve or what product to build.

Self-organization doesn’t mean that the team doesn’t have any tooling constraints, or architectural constraints, or budget constraints, or timing constraints.

Self-organization doesn’t mean that the team decides who is on the team, how big the team is, or how much money everyone on the team should make.

Self-organization DOES mean that once the team is formed, and given a problem to solve, and a set of constraints to operate within, the team gets to decide how the work is done.

While any given team, in any given company, may have have latitude to make any or all of these decisions, in my opinion, that is not what is meant by self-organization as it pertains to agile.

I’m interested in your thoughts.

The post Some Thoughts on Self-Organization in Agile Teams appeared first on LeadingAgile.

Categories: Blogs

Psssst! I Can Get You Fixed Cost AND Fixed Dates!!

The Agile Management Blog - VersionOne - Thu, 02/12/2015 - 23:50

130614-110928-2486x1687

I have an offer you can’t refuse…

You don’t have to be afraid, just because I am Sicilian.

I am talking about Product Development here, not “garbage collection”.

I know it frustrates you that all this Agile stuff talks about uncertainty and fluffy stuff. I have a secret for you, however. It’s one of the most overlooked aspects of Agile. I will even let you in on this secret for absolutely FREE.

Here it goes…

In Scrum, there are fixed timeboxes or iterations we call Sprints. You probably knew that. However, what you probably didn’t realize is that if your Scrum Teams establish fanatical discipline and rigor around only releasing things that are in line with their strong and comprehensive Definition of Done every Sprint, you will have…

FIXED DELIVERY DATES!!!

What will undermine this is if they compromise on the various criteria in the DoD, effectively cutting corners and introducing risk into the product. Also, if they extend the Sprints, change the duration repeatedly, or have nonsensical practices like magical mystery Sprints where hardening, innovation, and planning suddenly take place then all bets are off in terms of having…

FIXED DELIVERY DATES!!!

So, let the Scrum Teams be responsible and empowered to make the critical decisions that no one else can truly and effectively make. They will make the product sound in accordance with changing customer needs and technological advancements by baking quality in, integrating along the way, practicing emergent design, improving by coming up with new ideas, and doing smaller increments of ongoing planning, as Scrum intended. The result will be…

FIXED DELIVERY DATES!!!

Now, we all know that a Development Team in Scrum is supposed to be 5-9 (7±2) people, right? If we use a blended rate of, say, $100k to represent the average salary for team members (including consultants), then we know for certain that a Development Team will cost $500-900k / year. Voila! We have…

FIXED COSTS!!

Now, we can figure out what a Sprint costs by doing simple division. Let’s say a Sprint is two weeks. That gives us ~$19,000-$35,000 / Sprint depending on the Development Team size. Further, let’s assume our releases are every 3 Sprints (6 weeks). Now we know that a release costs us ~$57,000-105,000. That’s a beautiful thing. That’s…

FIXED COSTS!!!

You can’t ask for more!!

No, I mean literally, you can NOT ask for more; like Fixed Scope, for instance. In order to get fixed costs and fixed delivery dates in Scrum, the trade-off here is that the Scope is flexible. This is good, don’t freak out.

Having flexible scope ensures that we are able to roll with the punches and change as customer needs change, technology changes, and most importantly, business priorities change. To help us with this, we want the Sprints to be as short as possible. If we have one week Sprints, then we can formulate smaller increments in planning and ultimately have very granular refinements in our strategy rather than very drastic course corrections which are costly.

We still have higher level elements of planning that map to overall strategy: Vision, Roadmap, Release level planning, and insisting upon a Sprint Goal for every Sprint. This helps to keep us on target and focused with our longer term strategy.

So, not having fixed scope is a good thing. We could still have releases that are structured around fixed scope instead of fixed delivery dates. But it’s simply not realistic or REAL WORLD to expect to have more than one element fixed, one element firm, and one element flexible from among Scope, Cost, and Time. Those who demand to have all three fixed (so-called “firm fixed price”) are best served in taking this up by seeking an audience with OZ in the Emerald City, since they are indeed in fantasy land…

So, there it is:
FIXED DELIVERY DATES and FIXED COSTS

Happy weekend!

Peace and blessings-

Daniel

Categories: Companies

Mixing Lean UX and Agile Development

Scrum Expert - Thu, 02/12/2015 - 21:39
Carbon Five has been using Agile XP from our very beginnings 14 years ago. Six years ago we started on a deep dive into Design Thinking inspired by collaborations with the Stanford d.school. We then extended those learnings, integrating Lean UX techniques, to help our clients focus the team’s development power in a direction more closely aligned to a viable product market fit. Using two specific case studies and learnings from several other projects, this presentation walks attendees through the weekly cadence used at Carbon Five during product development. This ...
Categories: Communities

Socrates Canaries, Tenerife, Spain, February 26 – March 1 2015

Scrum Expert - Thu, 02/12/2015 - 17:05
Socrates Canaries is the Spanish stage of the International Software Craftsmanship Gathering, a series of events for open-minded software developers who want to improve their craft and the software industry as a whole. The local Software Craftsmanship community in the Canary Islands organizes it. The agenda of the Socrates Canaries International Software Craftsmanship Gathering follows the rules of the open conference where the participants create themselves the schedule of the event. Proposals are presented during the event itself in the mornings, and voted by the participants right after. This event is ...
Categories: Communities

The Simplest Systems Thinking Exercise - How to Make Toast.

For many years one example of process thinking, resource gathering, requirements, implementation and acceptance criteria has been the exercise - make PB&J sandwiches.  I've done this with groups to discuss the simple task that we typically overlook as "experts" in sandwich making, that perhaps a 5 year old will find difficulty glossing over the - get bread - instruction.


Here's a TED Talk by Tom Wujec who has analyzed a similar exercise and draws some powerful conclusions from many iterations.  Watch it and then rethink the simple acts in your life.




So tell me again why group collaboration is important when you are solving wicked problems?

See Also:

Visual Thinking


Categories: Blogs

You Don’t Know Jack (or Jill)

Tyner Blain - Scott Sehlhorst - Wed, 02/11/2015 - 15:25

Candles

You’ve got some shiny new segmentation data about prospective customers; how much they earn, where they are located, how old they are. How does that help you make decisions about your product? You know this information, but you don’t really know your audience, or why they might become your customers.

Customer Needs Are A Function of Intent

Healthy Food

Last month we looked at a single example of a customer expressing their wants instead of their needs – as most customers do.  The main point is to keep in mind, that what a customer “wants” is really the satisfaction of a need – which reflects an intent. In last month’s example, the desire to sort a list is really a reflection of a need to select healthy food items, arising from an intent to be healthy.

This perspective is useful when thinking about your product, and questioning / prioritizing investment in particular features.  Collecting these individual “what is the underlying goal?” insights informs your understanding of your market.

When you don’t know your customer’s intent, you don’t know your customer.

Kano for Product Managers

Who cares about ease of use?

I did a presentation in 2009 for the Product Management View, on applying Kano analysis as a product manager. Kano helps you understand the nature of value associated with features and incremental improvements in features.  Good stuff.

As a product manager, the main benefit of using this approach comes from appreciating that any given feature – like ease of use of an upright vacuum – will be of greater or lesser importance to different users.

Combine these two ideas (understanding the underlying goal, and realizing that different users value that goal differently) to get an understanding of what is important to whom, and why.  This definitely helps, but still leaves you with a bit of a mess, as you realize that not everyone wants every thing.

Segmentation Based On Intent

acrylic hammer hitting nail

On a walk the other day, I was listening to Brian Shea‘s interview with Susan Baier of Audience Audit, who really hit the nail on the head.  Susan helps agencies understand the intent of their client’s customers and prospects.  In the interview, Susan describes this in terms of attitude, opinions, and motivations.  My inner monologue was rattling off intent, goals, context, jobs-to-be-done.  Different language, describing the exact same thing.  This is a great listen for any product manager or marketer, who is responsible for, or relies upon, an understanding of their market.

Susan provides a great example, describing work she did for one of her clients, in helping them understand the customers for scented candles.  Check out the interview if you want more specifics, but here’s one aspect I remember (paraphrasing, and all mistakes are mine):

Some people buy scented candles because the aroma helps them manage their mood (relaxation / aromatherapy).  Their intent, when making a purchase decision, is to become relaxed – and duration of scent is an important criteria for satisfying their needs.

Some people buy scented candles because they are decorating.  Their goal is aesthetic – and often they would desire a completely unscented candle, because it is part of an ensemble achieving a particular appeal, and introducing an additional scent would detract from the appeal.

Some people buy scented candles as gifts for others.  Their buying choices are influenced by the packaging (“Oh what a lovely gift!”) and the brand perception (“Wow, you really splurged, getting me ‘the best,’ thank you!”) because their job is to give a great gift.

All three of the people above could make $120,000 per year, be 43 years old, and live in the same subdivision; they could all be (otherwise) identical members of any demographic analysis.

This is exactly the kind of thing that matters for us as product managers.

Companies Have Identities Too

I’m not talking about the corporation as a legal “person” thing we do here in the USA.  Companies are driven by goals and intents.  I’ll save a discussion of Bowman Clocks for another post, and for now will contrast two hypothetical companies.

Two companies are competing in the hair-cutting market.  They are both opening chains of salons, but there is a big difference in terms of the strategies the companies are pursuing – specifically, “who” the companies are trying to be.  One company is trying to be the best low-cost and low-value provider (cheap cuts).  The other company is trying to be the best high-cost and high-value provider (a pampered experience).  Both companies need to do many of the same things, and each company will value different investments differently.

Just as different candle-buyers have different goals, so do these hair-cutting businesses.  Imagine you’re selling software to these hair cutters, and you need to know what to prioritize for the next release of your software.

  • The low-cost salon would love to reduce the time spent scheduling appointments – maybe you could build an online reservation / check-in capability.  This increases their throughput and/or reduces their cost structure.
  • The high-value salon would love to “remember” how best to pamper their clients on return visits, so building out some capabilities for the stylist to surreptitiously glance at his phone and “remember” that Fifi the Pomeranian is recovering from surgery. This increases their word-of-mouth referrals by improving the customer experience, allowing them to grow their customer base or charge higher prices.

While the concept of identifying intent-based personas is easy to describe in terms of individual consumers (B2C), it applies just as effectively when companies are your customers (B2B).  Don’t make the mistake of assuming that intent only matters for consumer products.

Connecting the Dots

When we connect the dots from the sections above, to create a successful product, you must solve the right problems for the right users. Intent is a useful lens for identifying users (or buyers) who will value the same solution to the same problems.

Intent-based market-segmentation drives a tighter, better product.

That’s it in a nutshell.  Thanks again Brian and Susan for inspiring this article.

 

 

Categories: Blogs

Posted: Creating an Environment of Leadership

Johanna Rothman - Wed, 02/11/2015 - 14:55

My most recent Pragmatic Manager , Creating an Environment of Leadership is up.

If you like these tips and the ones in Discovering Your Leadership, check out the Influential Agile Leader.

Gil Broza and I are offering the Influential Agile Leader twice this year: once in San Francisco, and once in London. The early bird deadline for registration is Feb 15.

If you are trying to transition to agile and you’re having more challenges than you expected, you owe it to yourself to participate.

If you have questions, contact me. I’m happy to answer them.

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.