Skip to content

Feed aggregator

A Break to Reflect and Unlearn

Evolving Excellence - Wed, 04/13/2016 - 17:33

walking_19123519Over the past few years I’ve been working hard on cultivating positive habits. New habits can be powerful. But habits can also create barriers that limit our perspective, which can hinder kaizen, creativity, and even our knowledge of ourselves. The proverbial “rut,” and we’ve all been there at times in our lives.

Sometimes we just need a break to re-center, recalibrate, recharge, or readjust your horizons. In the Zen world, this is datsuzoku, a break from the routine. Datsuzoku can be as simple as getting a good night’s sleep or as common as taking a week of vacation.  It is also a great time for reflection.

I have a fairly standardized reflection routine, hansei, that includes a daily reflection in the evening, more extensive monthly and quarterly reflections, and an in-depth annual reflection where I also set goals for the upcoming year.

How am I doing, mentally, spiritually, and physically? What am I grateful for? What do I need to forgive myself for? Am I on track to achieve my personal and professional goals? What countermeasures do I need to put in place? What new opportunities can I create? What should I do more or less of? What activities or thoughts should I stop? Regularly reflecting and asking (and answering!) those questions is critical for effective professional and personal leadership.

I’m currently back in Hawaii for a few days, a break from the routine that helps augment a quarterly reflection. Hawaii is a special place for me as my wife was born here, we were married here, and the wind, sun, and waves seem to transmit and infuse nature’s energy in a deeper and more meaningful way than other tropical locales. I may do some work in the early morning or late evening, but during the day I disconnect, soak in the ocean, read, and reflect.

It’s been a good start to the year and I’m happy with my progress toward several goals. As I wrote in January, each year I set a goal to “do something different” and this year it was to read a work of fiction from a different culture each month. So far this year:

The Kite Runner was especially good, while One Hundred Years of Solitude was engaging but difficult due to a large family where everyone had very similar names.

cvr-simple-leader-1 010816I have also made considerable progress on my own book, The Simple Leader, and it should be published in late May. The copyediting process was very humbling, but the comments I’ve received from other authors that have reviewed it are gratifying.

And, after Paul Akers inspired me toward the end of last year, I’ve continued my lean health journey and have reached my original goal to lose 30 pounds and become much stronger. Being in better shape than I’ve been in over 30 years feels great!  Now to sustain and refine.

As I was reflecting on my personal and professional goals I began to realize that some of them may be based on faulty assumptions, based purely on my perceptions (or, even worse, the accepted perceptions of others!) and bias rather than fact.

In the beginner’s mind there are many possibilities, in the expert’s mind there are few.
– Shunryu Suzuki

One of the core concepts of Zen is shoshin, or “beginner’s mind.” This is a perspective that is free of preconceived ideas and opinions, and is open to new thought. Embracing shoshin requires “unlearning” what you thought you already knew—in effect, creating a beginner’s mind.

As we become older and supposedly wiser, creating a beginner’s mind can become increasingly difficult. It becomes even more so when an entire team or organization needs to unlearn and develop a beginner’s perspective. Unlearning is critical in a Lean environment as so many of the concepts initially appear counterintuitive, such as one piece flow vs. batch production.

Being biased is a result of not having a beginner’s mind. There are many forms of bias – confirmation, loss aversion, conformity, survivorship, and anchoring just to name a few.

How do we create a beginner’s mind? Begin by focusing on questions, not answers. When observing a process, especially one you’ve seen many times, try to avoid jumping ahead to conclusions. Take one step (one question) at a time. Similarly, be aware that what seems like common sense may not be. Avoid using the word “should” as it implies a predetermined or expected outcome. Be careful with experience. What you already know should be an input, not a given. Be comfortable with saying “I don’t know.”

So when you reflect – daily, monthly, quarterly, or whenever, also take the time to think about your perspective. Do you need to unlearn? Do you need to free yourself from bias?  How will you do that?

Being honest with yourself will enhance the reflection process and help you make smarter, more rational decisions.

Categories: Blogs

Would you like to see a Batch Actions feature in Targetprocess?

TargetProcess - Edge of Chaos Blog - Wed, 04/13/2016 - 17:22

We’ve recently started developing a Batch Actions feature. As you know, creating a great user experience starts with understanding the needs and behavior of users. To achieve this, we’re looking for Targetprocess users who are ready to tell us about their use cases related to working (or not) with multiple work items at a time.

We’d greatly appreciate it if you could take 2 minutes to fill out this short survey. Your feedback helps us to make continuous improvements and grow as a tool.
https://targetprocess.typeform.com/to/wh1Kwg

//

Categories: Companies

SonarAnalyzer for Java: Tricky Bugs are Running Scared

Sonar - Wed, 04/13/2016 - 14:38

For the past year, the SonarSource team behind the SonarAnalyzer for Java has invested most of its time in developing a Symbolic Execution engine in order to find the kind of tricky bugs that are almost uncatchable by developers unaided.

The SonarAnalyzer for Java’s new symbolic execution engine allows it to statically trace all the execution paths in a piece of code. We’ll probably do a blog post in the near future to explain all the related concepts: Program Point, Program State, Symbolic Value, Control Flow Graph, Stack of Symbolic Values, Constraints on Symbolic Values, … but for the time being let’s just see the engine in action.

Example 1 is a null pointer dereference in the Apache Tika project. The nullability of an object is guessed here from a test done in the code.

Example 2 is also an NPE in the Apache Tika project. This time the nullability is due to a badly handled exception.

Example 3 is a useless condition in the Spark project.

Example 4 returns to Apache Tika with a suspect unreachable branch.

Based on those few examples I guess it’s pretty easy to understand how valuable it can be to quickly get this information early in the development lifecycle. So how can you benefit from the SonarAnalyzer for Java? Either by getting on-the-fly feedback directly in your favorite Java editor with SonarLint for Eclipse or SonarLint for IntelliJ, Or by integrating SonarQube analysis into your build process to continuously feed the SonarQube server.

Tricky bugs are running scared. The hunt is on!

Categories: Open Source

Paging Through The File List Of An AWS S3 Bucket, w/ Node

Derick Bailey - new ThoughtStream - Wed, 04/13/2016 - 13:30

I’ve got some code running for the WatchMeCode media service that pulls a list of files from my AWS S3 bucket, and populates a database. The code has been working fine for a while now, but I recently wanted to add a sub-folder… and my code that reads the file list suddenly didn’t find the folders and files that I want.

js-reading.jpeg

S3:ListObjects Pages By Default. And Always.

The problem, as it turns out, is that S3 will always page your results for you – even when you don’t want it to. At least, this is my experience and is based on the evidence of having tried every possible way to not get Amazon to page my results.

The code in question uses the aws-sdk for Node, and is fairly simple:

In the response from the call, I get a meta-data structure that includes an “IsTrucated” attribute. If I examine this attribute, it is always set to true if you have a lot of files. That is, S3 will always page your result set (probably to keep the network traffic and memory use reasonable).

This means Amazon is paging the result set for me and I need to continue to make calls back to listObjects method, providing a “Marker” from which to start.

Paging With Markers

If you look at the docs for the aws-sdk, there is a “Markers” parameter we can pass to the listObjects method call. This parameter should either be empty (meaning, start at the beginning of the list), or set to the file Key to specify where the listObjects call should start.

The only problem is, the docs don’t tell you this in the definition of “Marker”. Instead, you have to scroll down to the response definition and look for the “NextMarker” attribute definition, which says this:

If response does not include the NextMaker and it is truncated, you can use the value of the last Key in the response as the marker in the subsequent request to get the next set of object keys.

That being the case, once the listObjects method executes the callback, you will want to check the “IsTruncated” attribute and make yet another call to AWS with the last Key from the result as the new Marker:

Once you have this in place, you are effectively paging through the list of objects in your S3 bucket.

Other Problems

This particular problem may not show itself when you first start using S3. I’ve been using S3 for several years now, and only just ran into this issue, in fact.

But here’s the real kicker: I hit this problem because I have logging turned on in my S3 bucket, and S3 is returning thousands and thousands and tens of hundreds of thousands of files from my listObjects call.

I ran into this because I didn’t organize my files correctly from the start. I should have used sub-folders for everything instead of putting the core files in the root of the bucket.

So, now I get to go fix that and migrate my files so I can filter the logs out of the listObjects call, using the “prefix” attribute.

Categories: Blogs

Product Owner Manager – Alone Together

Tyner Blain - Scott Sehlhorst - Wed, 04/13/2016 - 05:30

thumbnail of venn diagram

Product owners and product managers.  Two roles, often done by one person.  Together, the product people need to take an organization’s strategy, figure out the appropriate product strategy, and convert that into actionable work for the delivery teams to create the right product.  What does the product manager own, and for what is the product owner responsible?

Product Management Overlaps

A month ago, I was asked how to think about splitting the product owner and product manager roles and responsibilities by one of my students.  I drew a Venn diagram on the whiteboard and talked through my thinking on the subject.  This was a sidebar conversation, then we returned to the lecture topic, and I moved on.

Yesterday, I was reading an article about the overlap between product management and user experience, by Melissa Perri, who has feet in both worlds.  She drew a Venn diagram showing the unique and shared areas of responsibility and interests.  As an example, she shows customer problems as a shared responsibility.  I agree and incorporate the same perspective in my models of software development.

More specifically, the way I frame the collaboration between UX and product management – specifically for customer problems – is that I believe

  1. The user experience person is responsible for developing the point of view of which problems are most important to our customers.  They develop the deepest understanding of context, motivation, and capabilities; as well as user goals.
  2. The product manager is responsible for prioritizing the user goals in the context of all of the other goals that manifest as product strategy.  The product manager is bringing in the perspectives of competitive positioning, additional stakeholders and ecosystems, organizational capabilities, etc., and folding user goals into the bigger picture.

Melissa’s article is a good one, you should go read it.  She also talks about the challenges that arise from wanting to be a multi-disciplinary player on a team with rigid boundaries.  In addition to enjoying her article, and thinking more about the overlap of product with UX – and seeing her Venn diagram – I was reminded of a similar diagram I drew in March.

Product Manager and Product Owner

product manager and product owner Venn diagram[larger version]

[Ed: Product Manager is on the left, Product Owner is on the right]

The way I positioned these two roles was to acknowledge two “truths.”

  1. These are both (more than) full time jobs.  A product manager never runs out of valuable work to do – the market is always changing, there is always more to learn – and more to do based on what she’s learned.  A product owner never runs out of valuable work to do either.  Being downstream of continual learning means being the recipient of change – and that doesn’t even touch on the full time job of collaborating with the engineering and quality teams.  The two jobs cannot be done exceptionally well without two people sharing the work.
  2. Most companies only staff a single person to do the work.

We all commiserated a bit about this – and agreed that the survivable approach is triage – spend the limited time you have on the most important things.  A product manger or product owner must thrive in ambiguity and make the right calls about when “good enough” is, or isn’t, good enough.

A T-Shaped Team

The letter T

I generally find that the most effective individuals are the ones who are T-shaped.  They have breadth of perspective, knowledge, and context (the horizontal of the T).  They also have depth of insight, experience, and expertise (the vertical of the T).

In the product space (much easier to type than “the product management and product ownership space”), we can extend the metaphor to be three dimensional – and what is required is a balance of three perspectives

  1. A time horizon that looks out beyond the next few releases.  How will we manifest our organization’s strategy through product?  What role should (this) product play as part of a comprehensive strategy?
  2. A breadth of understanding of the market. Understanding the context in which the product has to compete to be successful.  What problems are most important to be solved, for whom?  How do we differentiate?  What is our strategy for right now?
  3. A depth of insight and excellence at execution.  What precisely does it mean to solve this problem, for this customer.  How will the team know that what they built is actually what is needed?

While it is possible to find someone who has strengths in all three areas, I believe the best chance for success is to have two T-shaped people, who share an understanding of the market, and divide and conquer in the ways they apply this understanding.  The product manager leverages an understanding of the market to develop hypotheses and strategy for the future.  The product owner leverages an understanding of the market to drive effective specificity in the product of the present.

When I’ve been responsible for doing both, I try and subconsciously change hats when I change perspectives.  It might be a waste of cognitive effort, but it seems to help me. YMMV.

Shared Space Ownership

product manager and product owner Venn diagram[larger version]

In the diagram above, there are a couple items squarely in the product manager side of the Venn diagram.  The decision about which market(s) in which to compete, is a decision made on the longer time horizon.  It isn’t something that would change sprint-by-sprint, or release-to-release.  Adding incremental markets, in sequential releases, as an intentional strategy can make sense.

Perhaps to greater benefit, a product manager can drive focus by specifying where the product will not compete. Focus is the glue that binds products together.

At the same time, there are items particularly suited for product ownership – as a practice and aptitude, regardless of role or title.  Transforming metrics of user success into measures of product requires melding insight of what and how with understanding of why.

Understanding how a customer defines success is something both product manager and product owner must know.  After working with many teams over the last few years, I believe there is only one right answer about who should own this, and who should participate.  And the answer is…

Given two people, one of them will be more available or more able than the other.  That person should do it.

Sorry there isn’t a silver bullet – if there is a silver bullet, it is to base your decision on the specific people involved, and not some formula spouted by a well-meaning organizational designer.  This is, of course, the approach to apply to all the items you might do, not just the 7 I included in the diagram.

While we’re at it – user experience is heavily involved in understanding how a customer defines success at solving a problem.  Perhaps we should work with Melissa to develop a three-lobed Venn diagram.  Did your employer staff UX, product management and product ownership on your agile team?

Categories: Blogs

Mechanic Driven Development

Agile Game Development - Wed, 04/13/2016 - 00:29
I was sitting around this morning with my coffee thinking, "what the world needs is another 'X Driven Development' approach to creating products".

Well, not really, but I have been thinking about this approach for awhile and observing it in action.  This post describes a variation on how some agile game teams have changed their approach to planning and executing sprints.

A video game usually has several core mechanics that we want to develop in depth.  For example, a platformer might have movement/control, environmental challenges/enemies and power-ups/rewards.

Given this, we can start by building three branches of the product backlog:





These are core mechanics.  They are core because we have to ship with all three and they are core to the player experience.  Outside the game industry, this might be called the minimum viable feature set.  This is different.
Mechanic Driven Development (MDD) focuses on delivering a narrow set of features each sprint, which are dynamically linked to move a mechanic's playability forward.
For example, let's say we have three team each centered around a core mechanic.  The movement/control team might break down their core mechanic even further:
Now we have running, jumping and offensive moves, each broken down further.  In what order does the team develop these items?
In mechanic driven development, the question for the team becomes, "what can we do over the next iteration to move this mechanic forward?".  In other words, "what's the most important work we can do for the movement/control to make the game more playable"?
To me, running and jumping would seem to be the most important.  Other people might feel differently.  We'll talk about it as a team (including the product owner).  This conversation builds vision, creates consensus and drives developer engagement.  The resultant sprint goal contains progress of some or all of the sub-mechanics derived from that discussion.
When a team does this, the result is a sprint that is measured by the progress of the mechanics rather than a collection of stories completed, etc.
What benefits does MDD bring over more traditional approaches?
  • It engages the team in discussing the game's mechanics as a target every sprint, not just the completion of a set of stories.
  • It creates opportunities for more creative input from the team.  A ton of small user stories from the backlog often suppresses creativity.
  • It keeps the product backlog very simple
  • It makes the sprint goal very meaningful (again, instead of just a collection of stories)
  • It drastically limits design debt

MDD is a direct application of the "working software over comprehensive documentation" value in agile.  It'll often result in a direct path to playability and an elimination of excessive work called out in a detailed plan written in a design document.  This approach can also be used with a detailed design document.  We just prioritize the work and sprint deliverables that grow the mechanic and reflect the emerging game against the plan.
Give it a try!
Categories: Blogs

Collapsed Commits

Pivotal Tracker Blog - Tue, 04/12/2016 - 22:00

Commit activity on a story can sometimes take over the conversation and make the activity stream unwieldy.  No one likes to sift through seemingly endless commits to find what they need.

To reduce the noise and the story length, we now collapse consecutive commits to show just the latest commit. You can still view how many commits have happened and all the commit details by expanding the commits. We hope this strikes the right balance between the conversation and reflecting the true the development of a story.

Collapsed Commit
Let us know what you think on Twitter or via Feedback in the app.

The post Collapsed Commits appeared first on Pivotal Tracker.

Categories: Companies

Agile Amped Greatest Hits from the First Ever Agile Alliance Technical Conference

BigVisible Solutions :: An Agile Company - Tue, 04/12/2016 - 19:00

This may have been the first ever Agile Alliance Technical Conference, but it was a big win for SolutionsIQ and Agile Amped! Not to be left out, Tiny Tim felt right at home and greeted visitors with his toothy grin!

Tiny Tim Selfie_AATC2016 

From experimentation to drive innovation to microservices and Conway’s Law, this tech-focused event really hit all the right marks! We are especially excited with the women who are (cue Beyoncé) “running the world” of software more and more today. Here are just of our favorite podcasts, hosted by a couple of our favorite females, Neville Poole and Leslie Morse!

Stay tuned for a jam packed May, when we fly out to the great state of Texas to the Change Management Conference on May 15th – 18th and Keep Austin Agile on May 26th.

Be Unstoppable – Subscribe!

dinoAgile Amped – all the greatest Agile content is within your reach. Subscribe now to receive instant email alerts when new podcasts are posted. Dino says do it – so do it.

 

The post Agile Amped Greatest Hits from the First Ever Agile Alliance Technical Conference appeared first on SolutionsIQ.

Categories: Companies

It is Bimodal, but in a Different Manner

NetObjectives - Tue, 04/12/2016 - 18:57
Gartner’s view of IT has for the past few years been focused on what Gartner considers essential bimodality. To quote the company: “Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and...

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

State of Agile: Culture Matters

Agile Management Blog - VersionOne - Tue, 04/12/2016 - 14:30

culture-matters-800x328So you want to adopt agile within your organization or perhaps your transformation is already underway. You are not alone as the number of organizations of all sizes adopting agile continues to grow. The increasing popularity of agile persists because organizations are realizing benefits including the top three cited benefits from the 10th annual State of Agile Report:

  • Ability to manage changing priorities
  • Increased team productivity
  • Improved project visibility

But there are barriers to adoption and success with agile. Be forewarned, depending on the current culture of your organization, the path to agility could be long and challenging.

In the 10th annual State of Agile Report, the top barriers to agile adoption center on matters of culture including 1) the ability to change organizational culture, and 2) general organizational resistance to change. And the most often cited causes of agile project failure include 1) the company culture at odds with agile core values followed by, and 2) lack of experience. Culture can profoundly impact agile transformation and can also cause existing agile projects to struggle.

Barriers to Further Agile Adoption

Culture is defined as a way of thinking, behaving, or working that exists in an organization.

So does the culture drive the behaviors, or do behaviors drive the culture? I say yes to both in this chicken and egg debate. We own our behavior and can change as individuals. While we each have a personal value and belief system that governs our thinking and behavior, we also are driven by the need for self-preservation, a survival instinct. Placed within an organization value system, people most readily adapt their behaviors to align with the perceived organization values, expectations, and observed behaviors. To change the thinking and behavior of a group requires a recognized shift in the core values and expectations.

So why is culture so challenging? First the new set of values and expectations must be clearly communicated and understood by the group. Then the group must trust that it is safe to actually shift their thinking and behavior. Without a strong foundation of trust, this may take a long time. Any inconsistent application of new values and expectations from authority figures will signal that it is not yet safe to behave differently further delaying change. Some will be confused about how to adapt or to fit into the new expectations and will need guidance. Some may not accept the new values. While others may hesitate to move outside their familiar comfort zone or fear losing position or influence. Human psychology is complex and the factors are situational making it difficult to prescribe a canned solution.

But, there are some common ingredients in successful agile transformations. Start by instilling the agile valves. Communicate, explain, and model them. Leadership needs to believe in these values as others will quickly see through empty words. Learn from others. Provide coaching and mentoring, whether from internal or external sources, to help people understand their new role and how to be successful.  People fear and thus resist what they do not understand or feel they will not be good at. It is easier to just do what you already know.

Too often organizations focus agile adoption efforts on instilling the mechanics of a process framework while failing to understand the underlying values and principles of agile. To successfully establish an agile culture, you must set the values, expectations, and beliefs to fundamentally change the underlying thinking and behaviors around the agile set of core values. Agile involves a different way of thinking about the work and the people.

The agile core values are expressed by the Agile Manifesto.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Agile values are rooted deeply in a sense of mutual trust and respect for one another, a belief that people matter and that empowered teams are the keys to excellence. Effective collaboration is essential, and continuous improvement around the delivery of value is the goal. Frequent feedback loops provide opportunity to inspect and adapt and to adjust priorities.

An agile culture requires a foundation of trust and transparency. It challenges the status quo, listens respectively to dissecting opinions, and views failure as an opportunity to learn. It empowers teams and promotes team performance investing in team building and growth of team members. It embraces a spirit of service and excellence. Servant leadership replaces controlling and directing.

Some organizations announce “Yes, we are doing agile” now. Then they quickly become disillusioned when they are not experiencing the expected benefits cited by agile organizations.

When you look a bit deeper, the reality is that they continued to think and behave as before. What they valued and believed did not change. They just adopted some new terminology and some process activity. They were going through the motions, but with no fundamental change in thinking. Sadly they failed to understand the philosophy behind agile values and principles. The culture did not change.

While agile transformation may not always be easy, it does provide benefits for those willing to stay the course. Find out more by downloading the 10th annual State of Agile Report.

State of Agile is a trademark of VersionOne Inc.

The post State of Agile: Culture Matters appeared first on The Agile Management Blog.

Categories: Companies

How You Can Get Valuable Time Back: Part 2

Leading Agile - Mike Cottmeyer - Tue, 04/12/2016 - 13:41

This is Part 2 in a series I’m writing about how you can get time back in your day, week, month, or project.   When a team reaches a natural velocity or throughput, how can you get more out of them? They physically can’t deliver any faster, given current conditions.  If we assume we have stable teams, let’s focus on governance and process.  Specifically, I’m going to talk about meetings again.  Why?  We all hate meetings but we all still have them.

In part 1, I wrote about a strategy to enable your email auto-responder to help manage the inbound meeting invites. In Part 2, I’m going to give you a simple strategy to start Spring Cleaning your calendar.

Spring Cleaning

If you’ve ever had a professional organizer come to your house for Spring cleaning, they may have employed a common strategy to weed through your crap.  It doesn’t matter if you are the CEO of a Fortune 500 company or some person appearing on an episode of A&E’s Hoarders. We all have too much stuff.  In this case, we’re not deciding if you should keep that mountain of National Geographic magazines sitting in the corner or all of those plastic shopping bags you’ve been keeping when you return from the grocery story. No, we’re going to inventory your meetings. Over time, we tend to accumulate meetings.  Time to take inventory and do some Spring Cleaning.

Inventory

As mentioned in the last post, some meetings have value than others. We’re going to need see which meeting we need to keep, which meetings we’re going to give away, and which we’re going to throw away.

Remember, meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are a waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you’re becoming a bottleneck in getting things done.

To start, I’m going to review every existing and new meeting request and bucket those meetings into 3 categories.

  1. Non value added but it is necessary.
  2. Non value added but it is NOT necessary.
  3. Value added.
1. Non Value Added But Necessary

Instead of automatically accepting the next meeting request, pause and consider the meeting’s return on investment to you.

  • Does the purpose of the meeting align with the company’s strategic goals and priorities?
  • Are the objectives of the meeting clearly defined?
  • Can the organizer explain specifically why you were invited and the value you will provide?
  • Will this meeting assist you in achieving my objectives?

If the first four questions were all answered with a yes, you should still ask.

  • Will anyone notice if you didn’t show up?
  • Is attending this meeting the highest and best use of your time right now?

If any of the first four questions were answered with a no, you should seriously consider declining the invitation. If I was Spring cleaning, this pile would be earmarked to donate.  Because we can’t “donate” meetings, I would propose having someone else attend on your behalf or find some way of being informed of the meeting outcomes or action items.

2. Non Value Added But It Is NOT Necessary

Did you read that right?  This meeting not only does not provide strategic value but it’s also not necessary.

If I was Spring cleaning, this pile would be earmarked for the trash.  This is like a meeting to prepare for a meeting.  Before outright refusing, try to meet the organizer part way.  What problem are they trying to solve with the meeting?  Can it be solved some other way?

To ensure everyone has a shared understand of what meetings are not NOT acceptable, I would recommend making an actual list.

Thou shalt not have meetings about putting cover sheets on TFS reports

3. Value Added

If I was Spring cleaning, this pile would be a keeper.  This is something that you want or need, as part of business process.  Release Planning, Sprint Planning, Demos… I see these as all valuable meetings.  They all require decisions.

Conclusion

Remember, every time you say yes to a meeting, you are saying no to something else.

The post How You Can Get Valuable Time Back: Part 2 appeared first on LeadingAgile.

Categories: Blogs

How You Can Get Valuable Time Back: Part 2

Leading Agile - Mike Cottmeyer - Tue, 04/12/2016 - 13:41

This is Part 2 in a series I’m writing about how you can get time back in your day, week, month, or project.   When a team reaches a natural velocity or throughput, how can you get more out of them? They physically can’t deliver any faster, given current conditions.  If we assume we have stable teams, let’s focus on governance and process.  Specifically, I’m going to talk about meetings again.  Why?  We all hate meetings but we all still have them.

In part 1, I wrote about a strategy to enable your email auto-responder to help manage the inbound meeting invites. In Part 2, I’m going to give you a simple strategy to start Spring Cleaning your calendar.

Spring Cleaning

If you’ve ever had a professional organizer come to your house for Spring cleaning, they may have employed a common strategy to weed through your crap.  It doesn’t matter if you are the CEO of a Fortune 500 company or some person appearing on an episode of A&E’s Hoarders. We all have too much stuff.  In this case, we’re not deciding if you should keep that mountain of National Geographic magazines sitting in the corner or all of those plastic shopping bags you’ve been keeping when you return from the grocery story. No, we’re going to inventory your meetings. Over time, we tend to accumulate meetings.  Time to take inventory and do some Spring Cleaning.

Inventory

As mentioned in the last post, some meetings have value than others. We’re going to need see which meeting we need to keep, which meetings we’re going to give away, and which we’re going to throw away.

Remember, meetings are supposed to be about the exchange of information.  Unfortunately, they are wildly inefficient and offer limited value.  For the most part, they are a waste of our time.  Nobody wants to listen to you go on and on about how many meetings you have, now that you’re becoming a bottleneck in getting things done.

To start, I’m going to review every existing and new meeting request and bucket those meetings into 3 categories.

  1. Non value added but it is necessary.
  2. Non value added but it is NOT necessary.
  3. Value added.
1. Non Value Added But Necessary

Instead of automatically accepting the next meeting request, pause and consider the meeting’s return on investment to you.

  • Does the purpose of the meeting align with the company’s strategic goals and priorities?
  • Are the objectives of the meeting clearly defined?
  • Can the organizer explain specifically why you were invited and the value you will provide?
  • Will this meeting assist you in achieving my objectives?

If the first four questions were all answered with a yes, you should still ask.

  • Will anyone notice if you didn’t show up?
  • Is attending this meeting the highest and best use of your time right now?

If any of the first four questions were answered with a no, you should seriously consider declining the invitation. If I was Spring cleaning, this pile would be earmarked to donate.  Because we can’t “donate” meetings, I would propose having someone else attend on your behalf or find some way of being informed of the meeting outcomes or action items.

2. Non Value Added But It Is NOT Necessary

Did you read that right?  This meeting not only does not provide strategic value but it’s also not necessary.

If I was Spring cleaning, this pile would be earmarked for the trash.  This is like a meeting to prepare for a meeting.  Before outright refusing, try to meet the organizer part way.  What problem are they trying to solve with the meeting?  Can it be solved some other way?

To ensure everyone has a shared understand of what meetings are not NOT acceptable, I would recommend making an actual list.

Thou shalt not have meetings about putting cover sheets on TFS reports

3. Value Added

If I was Spring cleaning, this pile would be a keeper.  This is something that you want or need, as part of business process.  Release Planning, Sprint Planning, Demos… I see these as all valuable meetings.  They all require decisions.

Conclusion

Remember, every time you say yes to a meeting, you are saying no to something else.

The post How You Can Get Valuable Time Back: Part 2 appeared first on LeadingAgile.

Categories: Blogs

The Ultimate Tester: Value Creation

Xebia Blog - Tue, 04/12/2016 - 11:10
Once upon a time, when project managers still thought that building software was a completely manageable and predictable activity, and testers were put in a seperate team to ensure independence, the result was shitty software and frustrated people. Even though the rise of the agile way of working has improved some aspects of software development,
Categories: Companies

Presentation on Nuggets for your Continuous Improvement Journey

Ben Linders - Tue, 04/12/2016 - 09:24
I gave a talk about Nuggets for your Continuous Improvement Journey at the Agilia 2016 conference in Olomouc, Czech Republic, and a full day workshop on Valuable Agile Retrospectives that was very well received. Continue reading →
Categories: Blogs

Guest blog: 4 Reasons Why to Focus on Scrum for the Success of Distributed Teams

Ben Linders - Mon, 04/11/2016 - 21:47
I met Hugo Messer a couple of years ago, when I connected with Bridge Global who started publishing guest posts from me. We talked about working with remote teams to find out that our thoughts on this are quite similar. In this guest post Hugo explores how Scrum can help distributed software development teams. Continue reading →
Categories: Blogs

How Can Analytics Help You?

Pivotal Tracker Blog - Mon, 04/11/2016 - 18:39

Now that Analytics are out of beta, you may be thinking, “Shiny! But how does this help me?” We’ll start to answer that by digging into some ways you can use the project Overview page to understand your team’s performance and identify areas for improvement.

Here are some of the most common questions people ask about their project:

  • Are we delivering as expected?
  • What did we get done?
  • What are we working on?
  • When will we be finished?

All of these questions can be answered on the project Overview page!

Measuring your team’s consistency

Good teams are consistent and predictable, and that allows them to deliver value at a sustainable pace—a core XP tenet. Being predictable lets you more reliably predict when something will be done. Velocity is an important metric, but perhaps even more valuable is the volatility of that measure. Lower volatility means a higher likelihood of completing work and hitting release markers on time. This post from Ken Mayer discusses volatility in much more depth.

Take a look at your Velocity chart in the top left corner of the Project Trends tab of the Overview page. It shows the velocity of the current and last few iterations, along with the team’s running velocity—that’s the average velocity of the last three iterations (by default). How does it look? Does your team consistently deliver the same number of points? Great! If not, why not? Dramatic changes or trends in your team’s velocity could be an indicator of other problems and might be worth investigating.

Is there a dip in your velocity? Check out the other graphs to see if they indicate any evidence of a cause for that dip. In this example, our running velocity took a downward trend starting from the Jan 20 iteration. In the Story Composition chart, look for bug walls or a glut of chores that could explain the drop in velocity. We did hit a bug wall in the Feb 3 iteration, which coincided with another drop in our running velocity. Cycle time increased in the Jan 27 iteration, so perhaps we should do a little more investigation there, too. Sometimes, an increase in cycle time can be tied to an increase in rejection rates. Is that what happened here? Looking at the rejection rate chart, we see that our team had a lower-than-average rejection rate that iteration, so there doesn’t seem to be a correlation. This means we should look for other reasons that the cycle time was higher that iteration.

Identifying changes in velocity and diagnosing the reason for those changes is a great way to home in on issues in your team’s process and find areas for improvement to keep you delivering consistently and predictably.

What features are we working on? When will we be done?

From speaking with our users, we learned that two of the most common questions that people have to answer about projects are, “What are you working on?” and “When can I have it?” In other words, what product features are in progress and how close are they to completion? Features are usually represented as epics in Tracker, and the Recent Epics section of the project Overview can help you answer those questions. Here you can see which epics were completed in the last two iterations and the status of epics that are in progress. The progress bars allow users to quickly visualize how much work has been completed, is in progress, and is unstarted for each epic. Estimated completion dates are calculated based on estimated stories in the Backlog, which will help answer the question, “When will I get my new toys?”

Additionally, the Recent Releases section can help you keep track of what work has just gone out and what’s coming up next. Any releases completed in the last two iterations will appear here, as well as the next Release and its estimated completion date.

We hope that’s enough to help you start answering questions and getting the most from our new Analytics. In our next post, we’ll look at how customer project managers helped us improve them.

As always, we welcome your thoughts and suggestions. Please use the Send us feedback link in the upper left corner of Analytics to submit your comments, or email tracker@pivotal.io.

The post How Can Analytics Help You? appeared first on Pivotal Tracker.

Categories: Companies

Agile Tribes

TV Agile - Mon, 04/11/2016 - 17:03
Being a good team isn’t easy. Apply the principles at the organizational level is even harder. The book Tribal Leadership is not very much known in Scrum community but the understanding of the dominant tribe culture in the company would help coaches to choose the right approach in Scrum organizational transformation. Every organization has tribes. […]
Categories: Blogs

Agile Metrics Beyond the Burndown Chart

Scrum Expert - Mon, 04/11/2016 - 16:17
How can metrics be used safely in coaching Agile teams? The classic Goldratt quote “Tell me how you will measure me and I will tell you how I’ll behave” signals the danger of using metrics to manage or motivate employees. This presentation shows and suggests approaches to Agile metrics that avoid the common pitfalls and shows some practical dashboards and the resulting chaos or calm they caused. This talk will show actual dashboards and metrics from actual industry engagements. It will explain how to safely capture and display these and how to teach an organization to see and understand its data. Be warned though, the techniques shown go beyond burndowns charts and cumulative flow diagrams. Watching this presentation you will learn: * The dangers of managing by metrics * Balanced approach to metric dashboards (less is more, but too little is disastrous) * Digital storytelling and patterns (examples of good and bad dashboards) * Coaching advice and dashboards * Visualizations of the edge – attention grabbing ideas for action Video producer: http://oredev.org/ Further reading: * Understanding the Scrum Burndown Chart * Lean Agile Metrics for Scaled Agile Systems
Categories: Communities

Targetprocess v.3.8.5: custom rules for Request closing, Planned Start/End date lanes, Customized card units update

TargetProcess - Edge of Chaos Blog - Mon, 04/11/2016 - 13:35
Minor Features A custom rule for Request closing

We've created custom rules that will close a request once all of its related items (outbound and/or inbound) have been closed. These rules will help to save time and effort, and will minimize the chance that a request unnecessarily remains open after all related work has been completed.  

3.8.5 pic7

Planned Start/End date lanes

We've also introduced the ability to set up views that group user stories, defects and other entities by planned start and planned end dates.  For example, let’s say you want to see which user stories are planned to end next week so you can increase their priority.  To do this, create a view that displays User Stories as cards. Select 'planned end date' as a lane and filter it using your desired date range: ?(It >= '11-Apr-2016' and It <='18-Apr-2016')   

10

 

Customize cards with 'Entity Type' and 'Planned/Forecast duration' units

Sometimes, it can be difficult to recognize what kind of item a card is through color coding alone.  To remedy this, we have added a new “Entity Type” unit for cards to help you immediately recognize if an item is a User Story, Task, Bug, Request, etc.   

3.8.5 pic5

We've also added units of time for planned and forecasted duration. So, you can now see how long an item is planned or forecasted to take. For example, an entity with a planned start date of April 8th, 2016 and planned end date of August 20th, 2017 will display a planned duration of “1 year, 4 months.” In tooltip, you can see more a more detailed representation of the duration -- e.g., “1 year, 4 months, 3 weeks and 2 days (500 days).”

new
Relations are shown independently from the specified context now

Previously, Relations were displayed based on the selected projects and teams in the top bar’s context/filter selector. A user had to select "All projects" and "All teams" to see all specified Relations. From now on, you'll be able to see all the available Relations no matter what context is selected. This change affects the Relations tab on entity view and Inbound/Outbound Relation cards.

The ability to map Team workflow to a final Project state only

You might be in a situation where you need a team to start work on an entity only at the final stage of its workflow. For example, when new functionality is ready, the Copywriter Team is assigned to write the relevant User Guide pages. You can now plan this out in Targetprocess by creating a team workflow that's mapped only to the final project state.

3.8.5 pic6

Math functions syntax simplified to work with nullable values

We've simplified the syntax of functions that are used in Reports to work with null data (data with no value assigned to it).
For example, in early versions of Reports, you would have to write the following formula to see requests' lead time in minutes:

IIF(StartDate != null, Math.Round((Today-StartDate.Value).TotalMinutes), -1)

This complex formula would have to be used for those instances when a request is not yet started and its StartDate is null. Now the formula can be written simply:

Math.Round((Today-StartDate).TotalMinutes)

Fixed Bugs
  • Fixed currency display for money fields
  • Fixed quick add form submit by enter key
  • Fixed some layout problems for custom card units
  • Fixed an issue with CKeditor: links did not open in a new window
  • Fixed a problem with creating attachments for Requests from messages sent from a third party tool like ServiceNow
  • Fixed broken search in IE11 after changing entity assignments
Categories: Companies

Knowledge Sharing


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