Skip to content

Feed aggregator

Agile DNA Webinar

Leading Answers - Mike Griffiths - Thu, 01/26/2017 - 01:05
This post is a follow-up to my Agile DNA webinar I hosted a couple of weeks ago. This was my first webinar for RMC and we had a great attendance with over 2,000 people registering for the event. The recording... Mike Griffiths
Categories: Blogs

New Year, New Blog

Jimmy Bogard - Wed, 01/25/2017 - 21:10

One of my resolutions this year was to take ownership of my digital content, and as such, I've launched a new blog at jimmybogard.com. I'm keeping all my existing content on Los Techies, where I've been humbled to be a part of for the past almost 10 years. Hundreds of posts, thousands of comments, and innumerable wrong opinions on software and systems, it's been a great ride.

If you're still subscribed to my FeedBurner feed - nothing to change, you'll get everything as it should. If you're only subscribed to the Los Techies feed...well you'll need to subscribe to my feed now.

Big thanks to everyone at Los Techies that's put up with me over the years, especially our site admin Jason, who has become far more knowledgable about WordPress than he ever probably wanted.

Categories: Blogs

How to implement Agile marketing

TargetProcess - Edge of Chaos Blog - Wed, 01/25/2017 - 19:36

Agile methods are being increasingly adopted by marketing departments who recognize the need to become more dynamic and responsive in today’s fluid digital landscape. Unfortunately, as is usually the case with Agile, the subject matter available online for this topic is already inundated with buzzwords and vague claims that Agile will help you improve your productivity, without many details on the practical aspects of implementation.

Agile has never been a cure-all panacea, and viewing it in this manner is destructive. However, if you can manage to dodge the endless stream of buzzwords and half-baked content marketing, you might find that agile is exactly the solution you need. Or, maybe you won’t. You won’t know until you try, but even a failed transformation will encourage new ideas and help your team to grow.  

Dodge the Buzzwords

Jurassic Park lazily reimagined with buzzwords.

Disclaimer: not all online materials regarding agile marketing are filled with buzzwords and shallow content. Check out these articles from PWC, Flite Agile Marketing, and David Baddock for some additional perspectives.  

Implementation Strategies:

Scrum it up:

  • Hold daily Scrum meetings so that your team can share what they did yesterday, what they’ll do today, and discuss any blockers they may have.
  • Experiment with working in sprints (2-4 week iterations of highly-focused work). But, if your marketing team is small, make sure you don’t neglect work items outside the scope of your sprint. You have a lot of ground to cover.
  • Establish sprint reviews to discuss what was accomplished during the latest iteration with colleagues and stakeholders. Explain your current campaigns, review metrics, and secure internal feedback.
  • Establish regular retrospectives where your marketing team can talk among themselves about how the last iteration went, discuss team morale, review the current agenda, and make plans to improve.

Kanbanize your work:

  • Establish a Kanban board with a backlog of work and custom swimlanes (to-do, planned, in-progress, rejected, done, etc.) that reflect your process. Make sure your board is readily available online for any remote workers. Transparency and open communication are vital.
  • Experiment with using WIP (work-in-progress) limits to maintain quality and focus. Multi-tasking is a myth.  
  • Every time you move a card further into the workflow, circle back and try to think about the item from the point of view of your target demographic.
  • Consider making it required for team members to leave a comment on work items every time they advance it further into the workflow. This is not for the purpose of documenting work for management. It should be an introspective practice to help each team member stop and reflect on the item. Marketers tend to be in a rush, which leaves room for mistakes.
  • Use visual encoding to make your board easier to comprehend. Color code according by responsible person, task category (social media, blog posts, SEO), or level of work (Task, User Story, Epic).
  • Planning your work to deliver “just-in-time” can help you to avoid the pitfalls of Parkinson’s Law (i.e. work expands to fill the amount of time allotted to complete it).
  • On the same token, when you make estimates, make sure you give yourself some extra time for securing feedback from colleagues.
  • Don’t let “almost done” work items pile up. Prioritize the items that deliver real value, produce an MVP (minimum viable product), share it with team members for feedback, refine the work, and finish the task.

Definition of Done

Test, measure, repeat:

  • Focus on small iterations and actionable new ideas over “big-splash” campaigns and unrealistic goals.
  • Actively test new strategies, stick with what works, and repeat the process
  • Fail faster. Don’t be afraid to drop a tactic that’s not working, no matter how much effort has already been put in.  
  • Never miss a chance to gather metrics on your campaigns. Using tools like Google’s URL Builder can help you measure what links are driving the most traffic to your website. Google Analytics (or some form of it) is an absolute must.
  • Data’s useless if it you can’t understand it. Make sure you take the time to properly analyze it. Consider using a data visualization software, such as Vizydrop (our free side-product, also integrated with Targetprocess) or Tableau (a great SaaS product with 14 day free trial).  

Facilitate collaboration and feedback:

  • Establish an internal communication channel for feedback and suggestions. Use this channel to encourage employee engagement on important social media posts to increase post reach and demonstrate brand community to your audience.
  • Make it easy for colleagues to contribute their thoughts to your brand. Get in the habit of asking for blog posts from other departments. Initiate conversations with quiet team members to get their perspective.
  • Establish a practice of bringing in one member from another team every week to contribute their ideas to your campaigns. You’d be surprised how many good ideas people keep to themselves, and it’s enormously helpful to get insight from a domain outside of your own.
  • Add a feedback widget to your online content. A simple “Was this article helpful?” can go a long way to securing metrics on what was most effective, and what areas need improvement.
  • As a marketer, you shouldn’t be managing social media, but rather facilitating it. Do what you can to make social media an organic process that everyone contributes to. Consider holding an internal workshop to establish guidelines.
  • If possible, integrate your social media channels with your internal communication tool. Create a public channel where all posts will appear so that everyone in the company can contribute.

Take and manage risks:

  • Establish a rotating Risk Management role. Assign one person per month to dedicate some of their time to actively seeking out new risks (threats and opportunities). Have this individual act as a devil’s advocate (see “10th man rule”) during meetings. This role can reduce the potential for groupthink and help your team stay responsive without damaging their focus. It will also help your team members grow their personal perspective.
  • Give your team the freedom to try new things. You’ll never get ahead of the competition by sticking with strategies you read on LinkedIn. Don’t copy innovation; be the innovation. If you fail, it’s no big deal; at least you learned.
  • Experiment on social media. A post that goes through two management gateways before being approved probably won't push anyone's buttons or make you stand out. Copying the style of competitors is similarly safe, but will leave your brand looking average at best. Don't be afraid to try new social channels and tinker with your brand voice.

Stop working so hard:

  • You can’t expect your audience to enjoy your content if you don’t even enjoy creating it. Make sure your team is happy with their jobs, and comfortable with the domain.  
  • At Targetprocess, we use Orange Time (optional time to work on self-education and side projects) to encourage employees to stay engaged at work and learn how to do their jobs better.
  • Eliminate Muri (excessively hard work) from your routine. If there are some necessary tasks which your team finds excessively difficult, try approaching the work from a different angle, or use Orange Time to learn how to better facilitate the tasks.
  • Measure your working habits, and try new personal strategies. I personally lose focus during the last hour of the work day. I no longer try to do difficult tasks during this window. Instead, I use this time for education, drafting tomorrow’s social media posts, and connecting with colleagues.
How to change your culture

Agile is not about what tool you use or what framework you adhere to; it’s almost wholly about your mindset and culture. Agile transformations need to happen both in the minds of your team members and in the actions of your management hierarchy. Changing the way people think is a monumental task, but there are some themes you can use to encourage this mental shift.

Focus on delivering value:

Many marketers have an unhealthy obsession with lead generation. Website traffic is driven by constant visibility via content marketing, social media, and good-old-fashioned spam. Of course, lead generation is vital for any business, but developing tunnel vision for this activity is dangerous. These lead-generation methods will not lose their relevance anytime soon, but the motivation behind executing them should revolve around delivering value.

Take some inspiration from journalism: deliver valuable information to your audience and empower them to make the best possible decision in order to make them feel like valued members of your brand community. Demonstrate the value of your product by delivering some of that value through your campaigns.

 

Different Lead Funnels

Picture via “I can’t tell you why our business is growing” by Ali Mese

Encourage freedom, responsibility, and trust:

If your company has a solid culture of trust, giving employees more freedom will enable them to be more responsible.  For example: you might not like the fact that your employees use Facebook at work, but you probably won’t get upset when they respond to a late night message on your company’s social channels.

As Michael Dubakov said in his his recent article on the future of Targetprocess: "A culture of trust in your company will slowly return a person’s trust in themselves, encouraging them to experiment and make mistakes."

If you can trust your team to be responsible, give them the freedom to work in the way that works best for them. Without this trust, freedom has the potential to backfire, so make sure you’re honest with yourself about the state of your company culture.

Dilbert Understands

 

Pitfalls to avoid
  • Lack of trust between team members
  • Lack of shared vision
  • Lack of transparency and communication
  • Securing metrics but not using them
  • Disregarding feedback and metrics in favor of your "gut instinct"
  • Assuming that your management tool or process will guide the transformation for you

These are just my personal thoughts on how to bring an Agile mindset to your marketing and public relations campaigns. If you have any strategies of your own, I'd love to hear them in the comments.

Categories: Companies

Refactoring Towards Resilience: A Primer

Jimmy Bogard - Wed, 01/25/2017 - 19:29

Other posts in this series:

Recently, I sat down to help a team to put in some resiliency in a payment page. This payment page used Stripe as its payment gateway. Along with accepting payment, this action had to perform a number of other actions. Roughly, the controller action looked something like:

public async Task<ActionResult> ProcessPayment(CartModel model) {  
    var customer = await dbContext.Customers.FindAsync(model.CustomerId);
    var order = await CreateOrder(customer, model);
    var payment = await stripeService.PostPaymentAsync(order);
    await sendGridService.SendPaymentSuccessEmailAsync(order);
    await bus.Publish(new OrderCreatedEvent { Id = order.Id });
    return RedirectToAction("Success");
}

I'm greatly simplifying things, but these were the basic steps of the order:

  1. Find customer from DB
  2. Create order based on customer details and cart info
  3. Post payment to Stripe
  4. Send "payment successful" email to customer via SendGrid
  5. Publish a message to RabbitMQ to notify downstream systems of the created order
  6. Redirect user to a "thank you" page

Missing in this flow are the database transaction commits, that's taken care of in a global filter:

config.Filters.Add(new DbContextTransactionFilter());  

I see this kind of code quite a lot with people working with HTTP-based APIs, where we make a lot of assumptions on the success and failure of requests. Ever since we've had RPC-centric APIs to interact with external systems, you'll see a myriad of assumptions being made.

In our RESTful centric world we live in now, it's easy to patch together and consume APIs, but it's much more difficult to reason about the success and failure of such systems. So what's wrong with the above code? What could go wrong?

Remote failures and missing money

Looking closely at our request flow, we have some items inside a DB transaction, and some items not:

Transaction flow

After the first call to the database (inside a transaction) to build up an order, we start to make calls to other APIs that are not participating in our transaction. First, to Stripe to charge the customer, then to SendGrid to notify the customer, and finally to RabbitMQ. Since these other services aren't participating in our transaction, we need to worry about what happens if those other systems fail (as well as our own). One by one, what happens if any of these calls fail?

  1. DB call fails - transaction rolls back and system is consistent
  2. Stripe call fails - no money is posted and transaction rolls back
  3. SendGrid call fails - customer is charged but transaction rolls back
  4. RabbitMQ call fails - customer is charged and notified but transaction rolls back
  5. DB commit fails - customer is charged and notified and downstream systems notified but transaction rolls back

Clearly any failures after step 2 are a problem, since we've got downstream actions that have happened, but no record of these things happening in our system (besides maybe a log entry).

To address this, we have many options, and each will depend on the resiliency options of each different service.

Resiliency and Coffee Shops

In Gregor Hohpe's great paper, Your Coffee Shop Doesn't Use Two-Phase Commit, we're presented with four options with handling errors in loosely-coupled distributed systems:

  1. Ignore
  2. Retry
  3. Undo
  4. Coordinate

Each of these four options coordinates one (or more) distributed activities:

Coordination Options

Which we decide for each interaction will highly depend on what's available for each individual resource. And of course, we have to consider the user and what their expectation is at the end of the transaction.

In this series, I'll walk through options on each of these services and how messaging patterns can address failures in each scenario, with (hopefully) our brave customer still happy by the end!

Categories: Blogs

Ron Jeffries to Keynote at Agile Alliance Technical Conference 2017

Scrum Expert - Wed, 01/25/2017 - 19:29
The Agile Alliance has announced the program for the Agile Alliance Technical Conference that will be held April 19 – 21 in Boston, Massachusetts. This event will focus on new advances, new challenges and new directions in Agile Software Development as applied to today’s technical work. The Agile Alliance Technical Conference will feature keynotes by Ron Jeffries, (RonJeffries.com), Chet Hendrickson, (HendricksonXP) and Dr. Anita Sengupta (NASA Jet Propulsion Laboratory). The three-day conference is built around three themes: Core Technical Practices, Team Technical Practices, and Technical Practices at the Organizational Level. It will explore topics such as new and updated core development practices; integration of user experience (UX) principles; advances in testing practices and automation; the evolution of tools and techniques that bridge development, deployment and operations; and the growing importance of Big Data across the entire spectrum of activities. Learn more about this conference on https://www.agilealliance.org/agile-alliance-technical-conference-2017/
Categories: Communities

Back to the Heart of Agile

Scrum Expert - Wed, 01/25/2017 - 15:30
“Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the center of Agile.” The Heart of Agile is a fresh look at Agile that strips away a lot of the cruft that has built up over recent years. Collaborate, Deliver, Reflect, Improve. Alistair Cockburn goes over the addition of kokoro onto the shu-ha-ri sequence, and its implications for agile. Following the heart of agile talk, Alistair Cockburn answers questions from the audience using the unusual form of answering with stories. They are more fun to listen to, and often more illuminating. Video producer: http://www.adventureswithagile.com
Categories: Communities

Play at Work: Releasing Human Potential Through Play

TV Agile - Wed, 01/25/2017 - 15:23
Are you frustrated by an unhappy and cynical workforce? Do you feel swamped by poor quality deliverables that no one wants? Do you dream of doing more of what you love and enabling others to do the same? If your answer is “Yes…” to one or more of these questions, then it’s time to act […]
Categories: Blogs

Top 3 Dependency Types

Leading Agile - Mike Cottmeyer - Wed, 01/25/2017 - 15:00

True agility comes by breaking dependencies between teams across the organization. It all begins by defining a rational system of delivery for the enterprise.  Next, healthy culture and solid practices should emerge within that rational delivery framework. For those who wish to transform their organizations, solving for the issues that get in the way of effectively practicing agile is what should guide you.  First, focus on the fundamentals of agile delivery, while systematically and methodically breaking dependencies. In this way, we can achieve true enterprise agility. So, what are the dependency types we should be looking out for?

3 dependency typesBusiness dependencies

May emerge when the backlog does not sufficiently meet the definition of ready, when there is too much work in process, or requirements are being shared across teams.  Often, multiple teams can be dependent on each other to deliver a single feature.

Structural dependencies

May originate from highly matrixed organizations, not having instantly available people, or having limited access to SMEs (subject matter experts).  Though companies try to keep people busy, sharing people between teams often results in delays.

Technical dependencies

May originate from large products with diverse technology, too much technical debt or defects, or low cohesion and tight coupling.

Where Dependencies come from
  • Lack of clarity.  Your system of delivery needs to be well understood. Your backlog must be clear and ready.  There must be a shared understanding of governance.
  • Lack of accountability.  People must know what they are responsible or accountable for.  Ensure you have the proper organizational structure.
  • Lack of progress.  You need metrics and tools to measure the system of delivery.  At scale, a physical team board is not enough to provide real-time progress.  Make sure you are leveraging the proper metrics to ensure you can see value flowing through the system of delivery and there is a balance between capacity and demand.

The post Top 3 Dependency Types appeared first on LeadingAgile.

Categories: Blogs

And now for something (not quite completely) different - Cognitive relativism in consultancy

Xebia Blog - Wed, 01/25/2017 - 13:40
Since joining the test automation unit of Xebia (June 2015), I have written some blog posts, all revolving around the topic of ..., well, ... test automation. However, there are a lot of other topics, across various domains, that have my interest and with regard of which I hold pretty strong, sometimes even passionate, views
Categories: Companies

Getting a Jumpstart on Organizational Agility with SAFe

BigVisible Solutions :: An Agile Company - Tue, 01/24/2017 - 18:00

The journey to Agility

Can you believe it is already the middle of January? Before we know it, Q1 will be over. Here at SolutionsIQ we are excited to place focus on the Agile community and to help each of you elevate your agility both personally and professionally. Our readers and followers are from every walk of life and at many different stages of their Agile development. That gives us reason to ask: Where are you in your Agile journey? Have you taken a chance to think about your longer-term goals and how to increase agility in your organization?

Whether your experience is primarily focused on team interactions or you are part of a large-scale Agile transformation, we would love to hear more from you and from your organization. Don’t forget we are here to help. In fact, here are a few of our best articles on leveraging the Scaled Agile Framework (SAFe) to inspire you to get a jumpstart on increasing organizational agility at your company this year:

  • 5 Reasons to Consider SAFe
    The Scaled Agile Framework (SAFe), codified by Dean Leffingwell but based on a tremendous amount of real experiences in many companies, is a guide to scaling Agile practices across the enterprise. While many enterprises are already implementing SAFe transformations across the organization, some remain to be convinced of the value of this approach. Here are just five reasons why an organization like yours wants to consider SAFe.
  • SAFe: DevOps & Systems Teams
    DevOps is a buzzword we hear a lot nowadays. This blog connects the dots between SAFe and DevOps, in particular what DevOps is, who are the key roles involved in it, and how systems teams factor in.
  • 5 Tips for a Successful SAFe Release Planning Event
    One of the most critical alignment events for every Agile Release Train is the Release Planning Event. This is an opportunity for teams working on a common Vision & Roadmap to come together and build a plan for delivering their next increment of value. Release Planning of this magnitude can be quite stressful, less valuable, and nearly disastrous if teams have not prepared. Here are five easy tips that will help make your next planning event a success!
  • 10 Tips for Putting People First in SAFe
    At first glance, the Scaled Agile Framework seems to violate the Agile value of “Individuals and interactions over processes and tools”. And although SAFe is just one approach to Agile transformation, it is a very effective one that many enterprises in every vertical are implementing. For any who suspect that SAFe may leave people feeling unheard, here are ten tips for putting people first in SAFe.
SAFe 4.0 in Your Organization

Last year the Scaled Agile Framework received a upgrade – from SAFe 3.0 to SAFe 4.0. Many organizations are excited about taking their SAFe transformations to the next level with the help of SAFe 4.0 certified Program Consultants. For individuals in an organization using SAFe to implement an Agile transformation, this means new learning opportunities. For existing SAFe practitioners, SAFe 4.0 addresses certain issues, the biggest change being the inclusion of Value Streams. For more about the changes in SAFe 4.0, check out our blog post “Look What’s New with SAFe 4.0”.

Placemat-FRONT-SAFe4-01_1000x775 

Implementing SAFe 4.0 with SPC Certification | Upcoming Opportunities

If your organization is using SAFe and you are interested in becoming SPC4 certified, we invite you to attend one of our upcoming public SAFe classes. These highly experiential classes provide the perfect place for you to learn what it takes to train others in SAFe practices and principles, while also giving you an opportunity to share ideas with other Agile and SAFe practitioners and to learn from some of our most seasoned Consultants. The class is designed for middle management, directors, executives, especially at the Program and Project level.

View Upcoming Courses 

The post Getting a Jumpstart on Organizational Agility with SAFe appeared first on SolutionsIQ.

Categories: Companies

Targetprocess v.3.10.9: miscellaneous improvements and bug fixes

TargetProcess - Edge of Chaos Blog - Tue, 01/24/2017 - 17:15
Minor features and fixed bugs
  • Fixed data losses that would occur when two or more users tried to edit an entity's Description at the same time. concurrent-description-edit
  • Redesigned the People selection tab for Project and Team viewsteam-project-people
  • Mashups: We reformulated the descriptions of mashup placeholders; they are more humane now. And, you can now save mashup code with the Cmd+S/Ctrl+S keyboard shortcut
  • Bulk Undelete for Projects and Users is now supported in REST API: api/v1/undelete/bulk  [{id:23, EntityType:'Project'},{id:24, EntityType:'Project'}]
  • Fixed data loss that would occur when one would type a Description and then close the entity's popup before saving
  • Improved the performance of Relations filtering
  • Fixed a case where the left menu would show improper view sets when Users were added/removed from Projects
  • Hide a redundant and confusing Epic -> No Feature row from Lists
  • Fixed Assignments search in Lists. You will now be able to find a User if their name not only starts with the searched keyword, but includes it in the middle
  • Fixed a prioritization error that occurred when reordering entities in an inner list of a parent entity view
  • Fixed 'No project' in the Projects and Teams Selection after a Project was deleted or became unavailable
  • Fixed a problem with renaming Boards in Firefox v.49 and v.50
  • Users will now be unable to link a Test Case to the same Test Plan more than once.
Categories: Companies

Separation of Concerns

NetObjectives - Tue, 01/24/2017 - 13:04
One way to transform code into more maintainable code is to separate concerns into different modules.  There is usually a question of when this should be done and how to do it.  I use testability as one determining factor of how to perform the separation.  Let’s start with an example: Original Code Here’s code from some production code that has been de-identified.   The method receives a...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Product Owner Assessment

Growing Agile - Tue, 01/24/2017 - 12:41
Categories: Companies

Lean Accounting: Does IT Need a Time Out on Time Tracking?

Is time tracking stunting your Lean transformation? Learn how to measure value, make finance happy, and enable continuous improvement with Lean accounting.

The post Lean Accounting: Does IT Need a Time Out on Time Tracking? appeared first on Blog | LeanKit.

Categories: Companies

Respect for People: Lean’s Neglected Pillar

Like Eliminate Waste, Respect for People can seem obvious, but it's not as simple in practice. Co-CEO Jon Terry explains how LeanKit operationalizes respect.

The post Respect for People: Lean’s Neglected Pillar appeared first on Blog | LeanKit.

Categories: Companies

What’s Minimum: Thinking About Minimum Viable Experiments

Johanna Rothman - Mon, 01/23/2017 - 19:12

When I talk about Minimum Viable Products or Minimum Viable Experiments, people often tell me that their minimum is several weeks (or months) long. They can’t possibly release anything without doing a ton of work.

I ask them questions, to see if they are talking about a Minimum Indispensable Feature Set or a Minimum Adoptable Feature Set instead of an MVE or an MVP. Often, they are.

Yes, it’s possible you need a number of stories to create an entire feature set before you release it to your entire customer base. And, that’s not an MVP or an MVE.

Do you know about Eric Ries’ Build-Measure-Learn loop? Or the Cynefin idea of small, safe-to-fail experiments? Here’s the thinking behind both of those ideas:

  • You have ideas you could implement in your product. If you are like my clients, you have more ideas than you could implement ever. This is a good thing!
  • You Build an idea for one product.
  • You Measure the result with data.
  • You Learn from that data to generate/reduce/change your ideas.
  • Do it again until you’ve learned enough.

When I think about the Build-Measure-Learn loop and apply it to the idea of a Minimum Viable Experiment, I often discover these possibilities:

  1. We have an MVE now. We need to define how to measure it and use the data.
  2. We don’t have to do much to collect some data.
  3. We can ask this question: What do we want to know and why? What is the benefit of gathering that data?

Here’s an example of how this affected a recent client. They have an embedded system. They thought that if the embedded part booted faster, they could find more applications for the system. In embedded software, speed is often a factor.

They chose one client, who had systems now. The Product Manager visited the client and asked about other vertical applications within the organization. Did they have a need for something like this system?

Yes, they did. They were concerned about speed, not just boot speed, but application processing speed.

The Product Manager asked if they were willing to be part of an MVE. He explained that the team would watch how they implemented and used the embedded system. Yes, they would all sign non-disclosures. The client also had to know that the team might not actually implement for real what the experiment was.

The customer agreed. The team implemented four very small performance enhancements—only through the happy paths, no alternative/error paths—and visited the customer to see what would happen. It took the team three days to do this.

The team visited for one day to watch how the client’s engineers used the product.

They were astounded. Boot speed was irrelevant. One specific path through the processing was highly relevant. The other three were irrelevant for this specific customer.

This particular MVE was a little on the expensive side. It took a team-week to develop, measure, and learn. There was some paperwork that both sides had to manage. If you have a different kind of product, it might take you less time.

And, look how inexpensive that week was. That week taught the team what one vertical product line needed and didn’t need. They managed to avoid all those “necessary” features. This client didn’t need them. It turned out a different kind of vertical needed two of them, and no one appears to need the remaining one.

The Product Manager was able to prune many of the ideas in the backlog for this vertical market. The Product Owner knew and (knew why) which features were more important and how to write stories and rank them.

That’s one example of an MVE. Your experiments will probably look different. What’s key here is this question: What is the smallest thing you can measure that will provide you value so you can make a decision for the product?

Categories: Blogs

Modifying the Definition of Done

Scrum Expert - Mon, 01/23/2017 - 18:17
Having a good Definition of Done (DoD) might be one of the most important technical asset of a Scrum team. This makes the difference between delivering at the end of the sprint fully completed business features or half-baked software. In his blog post “Changing the Definition of Done”, Ken Rubin discusses the situation where a Scrum team might want to change an existing Definition of Done. Ken Rubin starts with the case of a Scrum team that wanted to remove one check from its Definition of Done, because of technical problems that would have prevented them to deliver any results at the end of the sprint. There might always be some issues that could prevent a Scrum team to respect all the items listed in its Definition of Done. Thus the team could be catch the bad habit of taking shortcuts every time it meet a difficulty and Ken Rubin is against weakening the DoD during the sprint. If the issue isn’t considered a major one, you can always do a sprint review, but you have to fully inform the stakeholder of the items are not fully “done”. There is however no problems to make the DoD stronger if the team can do it without jeopardizing the delivery of software. In all cases, Ken Rubin recommends to change to the Definition of Done between the Scrum sprints. His conclusion is that “The definition of done is an important list of criterion that a Scrum team uses to determine if the [...]
Categories: Communities

Docker Recipes Update: Speed Up npm install In Mounted Volumes

Derick Bailey - new ThoughtStream - Mon, 01/23/2017 - 17:52

Last Thursday I posted a short update to the Docker Recipes for Node.js Development ebook pre-sale, setting a stretch goal of 100 sales before today – Monday, January 23rd.d

And I’m happy to say that the goal was hit by Friday morning, at 9am!

Thank you

Over the weekend, sales bumped up to 125 total, easily outperforming my original goal of 100 sales by the end of January!

And with both the original, and stretch goal met…

The Early Bonus Recipe Is Yours!

As promised, I’ve updated the Docker Recipes for Node.js Development ebook with an early version of another great recipe:

Speed Up npm install in Volume Mounts

Here’s a preview of the current introduction for the recipe:

NewImage

I’ve tested the solution that this recipe provides, and have found that my npm install time – for an empty Express.js installation – has dropped from 30 seconds to less than 15.

That’s an incredible performance improvement, and it only took 1 line of configuration in my Docker image to make it happen!

Download Your Updated eBook

If you’ve already purchased the pre-sale ebook, use the same download link (or the link in the update email I just sent to you) to get your updated version.

If you haven’t yet purchased the book, but you’ve been dealing with slow npm install times in your Docker containers when using volume mounts, now is the time to pick up the book and get that problem solved!

It’s easier than you might think, but it’s one of those little secrets that no one would think of until after they see it in action.

The post Docker Recipes Update: Speed Up npm install In Mounted Volumes appeared first on DerickBailey.com.

Categories: Blogs

Change, or Else!

Illustrated Agile - Len Lagestee - Mon, 01/23/2017 - 14:31

For the past couple of years, my coaching assignments have often taken me on the road. While visiting new cities, my typical evening routine includes wandering the streets until I’m lost or tired (or both).

A couple of months ago during one of these walks I noticed something out of the ordinary. Walking towards me was someone carrying a box. She was visibly upset and it was quite obvious she was just let go from her job.

As she passed I noticed the logo on the backpack she was wearing. It was a well-known company who had recently announced a large layoff. While I don’t know for sure, I can only guess she impacted by it.

Perhaps there is more to the back story behind the circumstances leading to this person walking out of their place of employment for the last time. I’ll never know. But for some reason, her vicissitude stayed with me throughout the evening as I continued my meandering.

Fast forward a couple of weeks later when I stumbled on a paragraph referring to the iconic corporate dysfunction movie, “Office Space.” It was from the book “Cubed: A Secret History of the Workplace” by Nikil Savil. It read:

The ‘space’ in Office Space was largely a symbol – of an uncaring, even ruthless organization. Its real targets were the unholy expectations of the modern workplace, which asked for dedication and commitment, offering none in return.”

As I was reading this, my mind flashed back to the setting of the person who was walking the busy streets with a box in her arms and tears on her face. Initially, I wasn’t sure why I connected these two somewhat disconnected scenes.

But the more I thought about it, this mixture of images offered up a symbol of my own – of the glaring need for organizations to become renown for thriving people and collective resilience. An organization with a foundation of healthy, purposeful people fluently navigating an ever-changing world.

Now, I’m not naïve and understand the nature of business and capitalism so the trick will be how can these companies get from an “old uncaring world” to a “new thriving and resilient world” while still delivering results. There will be no way around it – this will need the hard, messy, unglamorous, in the trenches, roll up your sleeves work of change. There are no shortcuts. There are no last-minute pardons. There is only hard work.

The purpose of the upcoming series of posts (and Season Two of the podcast) is to look at this journey from the “old world” to the “new world.” Hopefully, we can begin to scratch the surface of how to focus our energy and where to put in the hard work.

To start, let’s look at how organizations generally respond to the need to change.

Change is ignored.

People throughout the organization can feel something is amiss. It takes forever to get anything done and when we do get something done it isn’t what’s needed. But there is never time to think about whats really wrong and what could be done about it. Short-term goals and the illusion of productivity and busyness overwhelms the need to change.

There is a perception of security in the status quo. It is often rewarded and “rocking the boat” becomes frowned on. So existing systems and processes are continuously patched and issues are glossed over. Running jokes often emerge (“We’ve always done it this way.”)

People want to change I believe but change feels daunting and the inertia of the status quo remains too strong to overcome. “Where do we even start?” is often the dilemma.

If you were to ask people in private how to solve pressing issues, the answers come pouring out of them. But implementing anything feels monumental and people have been burned for speaking up in the past so they would rather continue to suffer in silence. Morale is low and people are disengaged.

Reaction to the Need to Change: Nothing or very little.
Long-lasting Impact: Change will be demanded as organizational productivity and workforce engagement declines.
People Impact: Develop atrophy (the gradual decline in effectiveness due to under use or neglect) and/or apathy (just don’t care any more).

Change is demanded.

If the need for change is ignored long enough it will eventually be demanded or forced – typically by leaders of the organization. This may take months, years or decades but it will happen.

Sometimes this happens as an event or announcement. Perhaps an email announcing organizational changes or as a town-hall meeting setting a new direction. Sometimes this happens as a mandate or an ultimatum, “Change…or else!” or “Get on board or get out.

When change is demanded, the language used often consists of “I want…” or “I need…” statements from the one doing the demanding. For example, you will sometimes hear managers saying “I want us to be Agile.” or “I need everyone to go to Agile training.”

If a change requires an event or mandate, it’s too late. There may be short-term gains but it’s just a matter of time before another mandate is required.

If change events are a surprise to the workforce, the impact is often hard to overcome. Motivating change the next time will be even more challenging as trust will continue to erode.

Reaction to the Need for Change: Command-and-control behaviors. Plans and decisions made in secret. Shock and awe.
Long-lasting Impact: Extreme highs and lows. Wild-swings of emotion or “change whiplash.” Eventually, events and mandates will lose their impact as the organization becomes numb to them.
People Impact: On-edge and fearful. Begin to isolate themselves and find safe places. “Just keep my head down and do my job.” Relationships begin to fracture and each change event diminishes trust a little more each time. As Seth Godin states, “…an ultimatum is an emotional affront, a deliberate break in a relationship.”

Change is attempted via willpower.

The consequence of ignored change and multiple demanding change events will often “freeze” an organization over time. This could be because of the apathy or atrophy formed from ignored changed or from the paralysis of fear fostered when change is demanded.

Out of desperation, a group of people will often emerge to try and help thaw the organization by creating a movement to break out of the stagnation or pain. They know we need to change (because its been demanded over and over) but we don’t know how to change.

This is often when Agile comes into the picture and will save the day.

Sadly, Agile (or any other change initiative) is often willed on an organization by overlaying its practices and mechanics over the top of demoralized or fearful people. Our group of change agents (coaches) will give enough energy to bring a small burst of what feels like improvement. This is often because we’ve chosen an area of the company easy to change or favors are called in to make things feel better and faster (with HR, infrastructure, legal, support for example).

But momentum is fleeting. The gravitational pull of the underlying culture is still latched on to the “old world.” Slowly, energy wanes and the promise of change fades.

Initial Reaction to the Need for Change: A small group of people (often leaders or coaches) attempts change through sheer willpower.
Long-lasting Impact: As the foundational culture (behaviors) have not been addressed, things will actually feel worse. Belief in the possibilities of meaningful change dwindle and people will revert back to ignoring the need for change. Or, a demanded change event will need to occur again and the cycle of dysfunction continues.
People Impact: Tired, broken, and demoralized as there is a limited amount of willpower available.

Change is natural.

The next 3 blog posts (and Season Two of The Illustrated Agile Podcast) is dedicated to discussing a few thoughts on an alternative option to building a dynamic organization rooted in its ability to change. Not just once, but continuous natural change.

An option where:

Change is naturally embedded into the DNA of the organization. We can do this by building an ecosystem based on simple rules, new language, and refreshing behaviors.

Change is naturally embedded into the work we do everyday. We can do this by building a backbone for how work flows through an ecosystem and by living our simple rules. We begin to remove the friction surrounding this backbone and allow the system to evolve around it.

Change has natural ebbs and flows. We can do this by designing cycles of increasing change energy (hard work) and momentum followed by periods of consolidation, observation, healing and rest. We use this time for a period of restoration and to introduce fresh thinking.

For clarity, I wouldn’t say that “layoffs” or a “reduction in force” should never occur. Market conditions shift quickly and mistakes happen. Sometimes we hire too many people too fast. Sometimes we add people to the team who may not be a fit. Sometimes organizations merge and there is an overlap in responsibilities.

Becoming a Catalyst - Scrum Master Edition

The post Change, or Else! appeared first on Illustrated Agile.

Categories: Blogs

The Halloween's MVP

Agile Complexification Inverter - Mon, 01/23/2017 - 04:59
Here's the 2016 Pumpkin decorating contest loser.  It's been a real LEAN year for the Scrum team.
Have you heard of a MVP - Minimal Viable Pumpkin?

Minimal Viable Pumpkin (MVP)https://en.wikipedia.org/wiki/Lean_startup
Categories: Blogs

Knowledge Sharing


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