Skip to content

Feed aggregator

The Lead Time and Cycle Time Debate: When Does the Clock Start?

Recently, a group of my LeanKit coworkers and I were talking Kanban. The age-old debate surrounding the...

The post The Lead Time and Cycle Time Debate: When Does the Clock Start? appeared first on Blog | LeanKit.

Categories: Companies

Targetprocess Mobile Android Releases: 2.0 and 2.1

TargetProcess - Edge of Chaos Blog - Thu, 12/15/2016 - 16:31
Bottom navigation

We're happy to announce that we've updated the Targetprocess Android app with a material redesign and more intuitive navigation. We've placed all of the user's main entry points into one place. Views, Search, Quick Add, Notifications, and User Profile are now easily accessible from tabs in the bottom bar with just one click. We hope this ease-of-access will improve your experience with our app.

navigation

Views List

Along with improved navigation, we have also updated the Views List. If you have favorited any views, you will now find a folder with your favorite views.

Searching for views will now yield results for both hidden and visible views. Just a reminder that you can update the changed view configuration and context by swiping down on the Views List.

menu

Me tab

In the ‘Me’ tab you will find an updated Feedback form – don’t hesitate to use it and share your ideas with us

Categories: Companies

The Customer Pain Map

Xebia Blog - Thu, 12/15/2016 - 16:28
“Ouch, that really hurt.” “What was it?” my sparring partner replied. “The choke or the overstretching of the elbow joint?” “The quick throw, I had no time for proper fall breaking.” I replied. It happens in our sport, we try and experiment and try to find the best way to perform a technique. The goal
Categories: Companies

Linking Animations to Scroll Position in React Native

Xebia Blog - Thu, 12/15/2016 - 12:37
When you want to link a custom animation to the scroll position in a ScrollView, like in the card example below, you are in for some bad performance on low end devices. Let’s figure out why and learn how to make it buttery smooth. Read more
Categories: Companies

Kanban Calculations: How to Calculate Cycle Time

In my last post, I talked about the basic metrics of flow (cycle time, throughput, and WIP)...

The post Kanban Calculations: How to Calculate Cycle Time appeared first on Blog | LeanKit.

Categories: Companies

Agile2017 Call for Speaker & Registration Open

Scrum Expert - Wed, 12/14/2016 - 18:07
The Agile Alliance invites leaders in Agile development to answer the Call for Submissions for Agile2017, Agile Alliance’s global conference that attracts practitioners, academia, business and vendor-partner community members worldwide. Agile2017 will take place August 7-11 in Orlando, Florida. Competition to speak at this Agile Alliance main conference is strong. Agilists with a story to tell should submit early. Speakers for the conference are selected via a comprehensive peer review process. Potential presenters are encouraged to carefully review the 17 available conference tracks that are accepting submissions and submit proposals under the track that most closely represents their proposed topic(s). The Agile Alliance also announced that registration for Agile2017 is now open. Conference attendees are encouraged to register and book hotel reservations early. A limited number of Super Early Bird registrations are available to Agile Alliance members on a first come, first served basis, providing a $750 discount over non-member registration fees. For more information about the Agile2017 conference, visit https://www.agilealliance.org/agile2017/
Categories: Communities

The Simple Leader: Leverage Productive Time

Evolving Excellence - Wed, 12/14/2016 - 11:42

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen


Amateurs sit and wait for inspiration, the rest of us just get up and go to work.
– Stephen King

Similar to the Hour of Power is the concept that certain parts of the day are more productive than others. Once again we’re all different in this respect, and it’s why some people are “morning people” while others prefer the evenings. I once even had a star employee who worked best from one to three in the morning, and insisted on being in the office at that time. (I won’t divert our discussion by describing the other problems that caused.)

I’ve long known that the most productive time of my day is in the mornings, especially the early mornings. I almost never set an alarm, but am generally awake at four. I take care of my morning meditation, breakfast, reading the paper, and then start the Hour of Power. After the Hour of Power, I usually hit the gym for an hour of strength or cardio work. After a quick shower, I head to the office, attend our morning team video call (our version of the “standup meeting” meeting I’ll describe later), and then get back into my productive time. I’ll use the pomodoro method to optimize the use of that time, which lasts until 11:30 a.m. or so.

While I find that my mornings are usually very productive, afternoons are far more difficult. I find it harder to maintain focus, even when removing distractions, and I know my mental acuity is not at the level it was in the morning. Therefore, I schedule phone calls, more mindless tasks, and errands during this time. A couple times a week, I’ll also take do a walking meditation on the beach. During this time, work (improvement) is still being done, just not the most critical tasks. I’m working on improving my mental productivity in the afternoon, but so far nothing has changed—perhaps reinforcing how powerful the productive time of my day is.

Evenings are a bit better than the afternoons, but my priority in the evening is my family. Therefore, I purposely don’t schedule any work tasks during this part of the day. When I have evening free time—which is common, since my wife requires more sleep than I do—I use the evenings to catch up on reading. If my brain feels a bit fried, I’ll turn on the TV. I end the evening with some reflection.

Categories: Blogs

Service Desk: major updates and On-Premise installation

TargetProcess - Edge of Chaos Blog - Wed, 12/14/2016 - 06:40

Good news everyone! Service Desk is no longer in beta, and is now also available for On-Premise users. On-Premise customers can have it installed in two ways: either as an IIS application or a Docker container. On-Demand users can still activate it from the General Settings page in Targetprocess.

New Design

The interface we started with as a beta was alright, especially compared to the original Help Desk which was released in 2008. Now, we've listened to your feedback and improved it further. Some of you mentioned low information density: large descriptions for requests meant that you could see just several items on the page. We tried to make the interface more compact, but most importantly added a check-box that allows you to hide descriptions, therefore displaying many more requests on the same page:

service_desk_ui_show_descriptions

Oh, before you ask: it will soon be possible to change the color of that blue interface area so that you can use your company colors, or just something you like more.

General Settings

Finally, we have added a Settings page right in the Service Desk application. The page is available if you login as a Targetprocess user with administrator permissions. Apart from the options we already had, like the ability to submit public requests, or to sign up or proceed as guest, we have also added some new ones. The most important addition is the ability to upload your own logo, with support for both images and vector graphics.

servicedeskiis_3

Projects and Custom Fields

If you tried Help Desk or the Service Desk beta before, it is very likely you faced an empty Product drop-down, or were puzzled as to why some Projects were available while others are not. Even if you guessed or read in the guide that you had to set the Product property in the info section of the Project details page, you still had to open all Projects one-by-one and check. We are sorry about that. Fortunately, we have released a more clear and convenient way of managing Projects in Service Desk: the Projects and Custom Fields tab in Settings.

service_desk_projects_and_custom_fields

Apart from showing your Projects, you can define which Custom Fields will be available to fill.

Personal Settings

You can now update your personal information and change your password. You can also upload an avatar which will be displayed in Targetprocess.

service_desk_personal_settings

Usability Improvements
  • You can now insert inline images using the Ctrl+V short-key, or just by dragging an image into a request's description or comments
  • Last Official Reply is now displayed only if there are more than 5 comments
  • Reduced load time of the main request list
  • We don't show closed requests by default anymore, but it is optional
  • In case there are requests from multiple Processes, we now group workflow states into categories like Open, Plan, In Progress and Done to avoid any messes caused by too many states

We'd like to thank those who already tried Service Desk, and especially the awesome people who shared feedback with us. Many of the improvements we released were inspired by you, and we are extremely grateful for you being with us and helping us make the product better. We are not done yet, so please share your thoughts on how we can improve it further.

Cheers!

Categories: Companies

12 Traits of a Great Release Train Engineer (RTE) + 3 Must-Have Tech Skills

BigVisible Solutions :: An Agile Company - Wed, 12/14/2016 - 00:30

As our industry continues to evolve, new roles are emerging. One of the more popular Agile scaling frameworks is the Scaled Agile Framework (SAFe). The SAFe framework defines a layered approach to scaling Agile to fit most organizational needs. One of the key roles in SAFe is that of the Release Train Engineer (RTE). Since this is a relatively new role, HR departments and leadership teams are wondering – “If I’m looking for a really great RTE, what would I be looking for?”

Let’s start the discussion with a description of the RTE role as defined by the Scaled Agile Institute (SAI):

“The Release Train Engineer (RTE) facilitates Agile Release Train processes and execution. The RTE escalates impediments, helps manage risk, helps ensure value delivery, and drives continuous improvement.”

The RTE acts as an Uber ScrumMaster, thus will share many of the traits of a ScrumMaster. Unlike the typical SM whose primary focus is on the team, the RTE will interact with various levels of the organization, thus must have a much more refined and broader understanding of how Agile/SAFe is delivering value to the organization. Figure 1 below concerns the principles of Lean-Agile leadership.

safe-principles-of-lean-agile-leadership

Figure 1. Principles of Lean-Agile Leadership

Keeping these principles in mind, let’s look at the 12 traits that make a great RTE.

12 Traits of a Great Release Train Engineer (RTE)
  1. Agile Mindset – A great RTE not only understands the foundations of Agile and SAFe, (s)he embraces an Agile mindset. (S)he not only teaches Agile; (s)he IS Agile. It is in the state of being Agile that one exudes the confidence in knowing the value that Agility provides. A great RTE will be value focused and guided by the Lean-Agile principles as outlined above in SAFe, with a concentration on Systems thinking.
  1. Courageous – Like a ScrumMaster, a great RTE has the courage to say what needs to be said in a respectful and tactful way. (S)he respects the authority and direction of management, but has the courage to deliver the truth, even if it’s not what they want to hear.
    • The RTE must have the courage to say “no” sometimes in order to avoid over committing the train to taking on too much work.
  1. Servant Leadership – A great RTE is above all a Servant Leader. (S)he leads the team by example, by actions as well as by words. (S)he earns the respect of the ART, from both the leadership as well as the teams.
    • The RTE will serve the SM team as the primary escalation contact and be ready to do whatever is necessary to keep the train rolling.
    • The RTE steps up when called upon to work with the SAFe Release Management Team, Product Management Team and other representatives of Shared Services.
  1. Integrity – A great RTE is a person of integrity. They hold themselves accountable to keep their word and deal fairly with everyone.
  1. Facilitator – A great RTE is comfortable presenting in front of the team and management. They have an arsenal of tools and techniques to keep the participants interested and engaged.
  1. Negotiator – A great RTE understands that most things are not black and white. There are many shades of grey, where matters must be negotiated to achieve an agreement that is palatable to all parties involved.
  1. Communicator – A great RTE can deliver a message with tact, being sensitive to how the message is received by the team or by management.
  1. Teacher – A great RTE nurtures the team’s understanding of Agile principles and practices through the use of workshops, Agile games, and presentations.
  1. Mentor – A great RTE serves to guide individuals in the Train to a clearer understanding of the processes and approaches implemented by the ART.
  1. Honest and Transparent – A great RTE understands the value of transparency. Bad news is not like wine – it does not get better with time. Agile does not fix problems, but it does expose them. A great RTE knows this and approaches the matter with the intention of informing the broader group and working together on a resolution.
  1. Critical Thinking – A great RTE has the ability to think on their feet. (S)he can quickly analyze a situation and organize the team around a solution. (S)he does not have to define the solution but has the savvy to guide the conversation.
  1. Lifelong learner – A great RTE understands that their learning journey is never over. (S)he strives to build their skills through continuous learning. Learning comes from many places: formal classroom training, books, blog posts, podcasts, seminars, and other colleagues – everyone around you can teach you valuable lessons you can apply every day in a team setting.
3 Must-Have Technical Skills

Great RTEs will have “T-shaped” skills. Meaning, (s)he will have a broad understanding of not only Agile, but also of software development, as well as subject matter expertise associated with their industry. Their background will typically include the role of Project Manager where organizational, time management, budgeting, scheduling are all critical skills. In particular, a great RTE will have deep knowledge and experience in the following technical (non-software) areas:

  1. The SAFe Framework – A great RTE will have a deep understanding of Lean-Agile frameworks in general, but an especially deep grasp of the Scaled Agile Framework.
  1. Agile Budgeting – Your RTE must have a solid understanding of how budgeting works in a Scaled Agile environment. They will grasp the concept of taking work to the team versus project-based funding models.
  1. Agile Metrics – A great RTE understands which meaningful metrics to track, how to interpret them, and how to course correct when the numbers are telling you things are headed out of bounds. Figure 2 below is an sample meaningful metrics you may want to use in your SAFe transformation and the benefit to the business:

 

sample-safe-metrics

Figure 2. Sample SAFe Metrics

Release Train Engineer Training Journey

Great RTEs will have not only the requisite experience, but will have also had the specialized training needed to understand the various Agile frameworks and techniques. Training combined with mentoring, coaching and experience is the recipe for growing great RTEs.

While certifications look great on a resume and are an indication the person has successfully completed a training program, they don’t always represent full understanding of the subject matter. So when considering candidates, seek to determine their understanding, as opposed to relying only on the credentials they have accumulated.

Accreditation Bodies

There are currently no accreditation bodies for RTE certification. However, there are a number of relevant certifications that it makes sense for an RTE to hold.

Scrum Alliance Project Management Institute
  • Project Management Institute – Agile Certified Professional – The PMI-ACP spans many approaches to Agile such as Scrum, Kanban, Lean, Extreme Programming (XP) and test-driven development (TDD.)
Scaled Agile Institute
  • Advanced ScrumMaster (ASM) – The Advanced ScrumMaster Curriculum is designed to build on the skills of a CSM. It broadens the scope from interaction with one team to interacting as a team of teams. Adding additional frameworks such as Kanban and SAFe into the materials learned in the fundamental CSM training.
  • Scaled Agilist (SA) – The Scaled Agilist (SA) certification is the foundational certification that demonstrates the candidate has completed the fundamental training in SAFe and successfully passed the exam. The associated course is “Leading SAFe”.
  • SAFe Program Consultant (SPC4) – The SAFe Program Consultant (SPC4) is the next level certification up from SA certification and demonstrates the candidate has successfully completed the four-day training course and passed the associated exam. SPC4 training provides the RTE with the skills and tools required to launch a new Agile Release Train.
Non-Accredited Training

There are also a number of extremely valuable training classes offered that do not result in an industry recognized certification. Value a candidates understanding over their ability to pass a test. In addition, find out what self-study a candidate has done.

Conclusion

Very little of what makes a great RTE great can be gleaned from a resume. As I said, accreditations don’t reveal a true understanding of the principles, values and capabilities that will make a person successful as an RTE. So as you search for RTEs, engage them in conversations that demonstrates the candidate’s stance, experience and motivations. And finally don’t forget to consider culture fit: as they say, “Culture eats strategy for breakfast.”

Like this? You’ll love Agile Eats

Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!

The post 12 Traits of a Great Release Train Engineer (RTE) + 3 Must-Have Tech Skills appeared first on SolutionsIQ.

Categories: Companies

The Six Lean Transitions that Got Us to Where We Are

NetObjectives - Tue, 12/13/2016 - 18:51
The Six Lean Transitions that Got Us to Where We Are At a recent meeting, Al Shalloway discussed the six key transitions in Lean that has led to where we are in the application of Lean to software development. We found it very helpful in understanding where we have come from, the advantages that each phase offered as well as the challenges inherent in them that needed to be addressed. Looking...

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

Improve Backlog Management with SpiraTeam 5.1

Scrum Expert - Tue, 12/13/2016 - 17:45
Inflectra has announced the release of SpiraTeam 5.1, the latest version of its award-winning application lifecycle management (ALM) suite. This version of SpiraTeam brings together major enhancements in performance and usability along with the ability to break the project paradigm for the first time. With SpiraTeam 5.1, you can take control of even the most complex programs. SpiraTeam 5.1 provides users with the ability to have complete traceability between items in different projects, the ability to view integrated program backlogs and the ability to quickly search across all items and projects to make associations. Cross Project Traceability SpiraTeam 5.1 lets you create reusable component projects that can be composed together to handle large-scale programs and system of systems. Unlike other tools on the market, you don’t need to manually copy items between projects, you can instead have a single set of shared requirements, test cases and tasks that are used as needed. Project Planning SpiraPlan 5.1 includes new program management functionality that lets you plan your agile backlogs across multiple projects with the new project group planning board. These new features let you view the backlog of the entire project at a glance and prioritize work across all of the projects in your program simultaneously. New Searching Capabilities Taking advantage in new database free-text indexing capabilities, SpiraTeam v5.1 has a completely redesigned search interface that lets you find information 80% faster than in the previous versions. The new ranking algorithms ensure you get the most appropriate information first time around. [...]
Categories: Communities

Define Done and Avoid Death Marches

Agile Game Development - Tue, 12/13/2016 - 17:41
How often do you reach an alpha milestone on schedule only to have post-alpha work bite you?  Extended crunch, cut features and assets result in burn-out and a game’s quality damaged by last-minute compromises to get it out-the-door.The culprit is usually “debt”.  Debt is that extra work which takes a feature from "works on my PC" to a feature that a player who buys the game could use. Like financial debt, development debt has an interest rate; the longer you hold onto the debt, the more expensive it becomes to eliminate. It's also not just technical debt.  Art and design debt exists as well.

What does “done” mean at your studio?  When I ask this question onsite, I often hear some anecdotes and definitions such as:    •    “It compiles on my machine.”    •    “I’ll know it when I see it.”    •    “It’s 90% complete”    •    “It’s coded” (or “it compiles”).    •    “It's done, but it needs final assets.”    •    “It’s first pass” (out of an undetermined number of passes)Usually there is no agreed-upon definition.  This is a big warning sign on the road to death-march-ville.One of the initial challenges in adopting agile is defining a more frequent and universal definition of done (DoD).  As with all agile practices, it’s emergent; Teams inspect and adapt the game and their work and continually improve the DoD.For Scrum every sprint must meet this definition of done before being accepted as done by the product owner.  For Kanban, a work item cannot be pulled into the next stage until it meets the definition of done in it's current stage.  For example, a rigged model cannot be pulled into animation unless all the naming conventions for the skeleton are met.Non-functional RequirementsA DoD is derived from a set of non-functional requirements.  These are attributes of the game that apply universally to all work , such as:    •    The game runs at a smooth, playable frame-rate    •    The game runs on all target platforms    •    The game streams off disc cleanly    •    The game meets all Facebook API standards    •    The code meets the coding standards of the studio    •    The assets are appropriately named and fit within budgets    •    All asset changes must be “hot-loadable” into the running game    •    …and so onNon-functional requirements are never done.  Any feature added or tuned can impact frame-rate, so by the end of a sprint we must ensure that any work added does not slow frame-rate below a minimum standard.  If it does, it's not considered done.Multiple Definitions of DoneBecause potentially shippable doesn’t always mean shippable, there often needs to be more than one DoD,  I’ve seen teams create up four DoDs, which cover anything from “prototype done” to “demo-able done” to “shippable done”.  These identify the quality and content stages that large features, which take longer than one sprint to be viable (called epics), must go through.  Keep in mind, that these definitions shouldn't allow the team to "waterfall" the work.  Even if you have a set of cubes flying around for targets, before animating creatures are ready, those cubes can't crash the game or impact frame-rate too much.  If cubes are killing your frame-rate, you have more important things to address before adding animating creatures!

Starting OutThe best implementations of DoDs start small and grow (that can be said of a lot of good practices).  Start by identifying a few of your larger areas of debt in a retrospective and pick some low hanging fruit DoDs.  For example, if basic stability is an issue, a definition such as "the game can't crash while using the feature" is a good starting place.  Don't be surprised if this definition impacts how much the team can commit to every sprint: quality costs...but that cost will be recouped with interest over time as practices are improved.

What Post-Alpha looks like with a Good Definition of DoneWhen we started using agile, I’d hoped we could do away with the alpha and beta stages of game development.  In practice, for major initial release of a game, we still needed time after feature-complete to balance the game.  What we did lose were the death marches and compromises.
Categories: Blogs

Consider Onions or Round Trip for an MVP

Johanna Rothman - Tue, 12/13/2016 - 17:13

I’m teaching a Product Owner workshop this week, and I had an insight about a Minimum Viable Product.

AN MVP has to fulfill these criteria:

  • Minimum means it’s the smallest chunk of value that allows us to build, measure, and learn. (Yes, Eric Ries’ loop)
  • Viable means the actors/users can use it.
  • Product means you can release it, even if to a small, specific group of test users

My insight came when I was discussing with the class how their data moves through their system. Think of data like an onion: there is an inside kernel and concentric rings around the inside. (If you prefer, a cut-down tree, but I like the onion.) Often, you start with that inside and small (round) piece of value. You then add layers around it, every time you do another MVP (or Experiment, if you’re prototyping).

The data has to do a round trip. That’s why I thought of it in circles like an onion. If you only implement half (or some other part) of the entire round trip, you don’t have the entire circle of minimum functionality.

This image on the left, where you see the feature go through the architectural layers might be a better image.

The actions that the user—whomever the user is—has to go into the system and come out. In an MVP, you might not have a very thin slice all by itself, but it still needs to be a thin slice.

When I think about the idea of the onion, I think, “What is the smallest piece I can define so we can see some results?” That’s the idea of the MVP.

I realize that MVPs might be useful for the team to learn about something in a small test environment. And, the smaller chunk of value you deliver, the more experiments you can run, and the faster you can learn. Maybe the idea of the onion, or the round trip through the feature will help you think about your MVPs.

BTW, I still have room in my online Product Ownership workshop that starts in January. Please join us.

Categories: Blogs

Keeping Remote Teams Cohesive, Part 2: Onboarding for Success

In my last post, you learned how hiring for a healthy remote team requires a thorough process,...

The post Keeping Remote Teams Cohesive, Part 2: Onboarding for Success appeared first on Blog | LeanKit.

Categories: Companies

Lean Coffee Table Experiment

Learn more about transforming people, process and culture with the Real Agility Program

screen-shot-2016-12-13-at-9-44-37-am

leancoffeetable.com

Trying this out today for a remote client meeting. So far, I like it. Will update after the meeting…

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Lean Coffee Table Experiment appeared first on Agile Advice.

Categories: Blogs

Productivity Patterns

Leading Agile - Mike Cottmeyer - Tue, 12/13/2016 - 15:00
My Past Experience

Be it get-rich-quick schemes or rapid-weight-loss solutions, the Internet is littered with a million improvement schemes.  In my many years of attempting to improve productivity for my clients and myself, I’ve tried just about everything.  Regardless if the post, podcast, or book is promising to do twice the work in half the time or that you can cram an entire work week into 4 hours, there is something out there for everyone.  My first venture into this productivity-focused world was way back in the early 90s, when I watched this horrible movie titled Taking Care of Business, starring Jim Belushi and Charles Grodin.  In the movie, an uptight advertising exec has his entire life in a filofax organizer which mistakenly ends up in the hands of a friendly convict who poses as him. The movie is still horrible but the organizer idea seemed to work for me.  

Franklin Covey Planner

From this movie, I discovered the Franklin Covey Planner.  Yep, my world was filled with A1, B1, C1’s. Alas, I couldn’t make it work.  Much like the guy in the movie, everything was in a little leather book with special pages (that were not cheap).  Unfortunately, if I didn’t have the book in my field of view to constantly remind myself, things didn’t get done.  I think I lasted a year, until I discovered the cost of refilling the book with new pages.

GTD

I then discovered GTD (Getting Things Done) by David Allen.  This was 15-20 years ago.  Again, it worked for a little while but I then found myself doing too much organizing and too little doing.  Things were going away from paper filing and everything in that system was all about paper filing.  Maybe I was doing it wrong.  It just wasn’t clear to me.  I didn’t see any real progress or productivity improvement so I just stopped doing it.

Personal Kanban

In mid 2009, in a moment of Internet serendipity, I ventured into the world of Personal Kanban. I think I searched “Zen” and up popped a website for a Kanban tool. I started using it and loved it.  Alas, that company got purchased by Rally and they are no longer taking registrations.  But, this has become the first system I have been able to stick with.  Just to try other tools, I soon switched over to LeanKit Kanban.  I’ve been using it ever since.  I like that it doesn’t make any promises it can’t keep. “Visualize your work, optimize your process and deliver faster”.

LeadingAgile Transformation Framework

In 2012, I joined LeadingAgile. Though we didn’t have a defined system at the time, a Transformation Framework emerged.  Since that time, when the system is followed, it works really well.  When things don’t work so well, the same failure patterns are present.

Productivity Rosetta Stone

productivity pattern

So, why do some methods work and some do not?  Why did I abandon the Planner and GTD systems so long ago but still use Kanban and LeadingAgile’s transformation framework?  Well, I started by listing common traits on a whiteboard and saw relationships and discovered some patterns.  Not only are there three things I believe every productivity system needs to work, I also see three things that are necessary to prevent you from abandoning that system.

I describe it as a Productivity Rosetta Stone.  For those unfamiliar, the Rosetta Stone is a rock slab, found in 1799. It was inscribed with a decree that appears in three scripts: Ancient Egyptian hieroglyphs, Demotic script, and Ancient Greek. The stone presents essentially the same text in all three scripts and provided the key to the modern understanding of Egyptian hieroglyphs.  I’ve applied my productivity Rosetta Stone to Scrum, Kanban, Pomodoro Technique, and even LeadingAgile’s Transformation Framework. All of them check out and it provided me with a key to better understand productivity patterns.

3 things to increase productivity: System, Ritual, Habit

1.     A system is a set of principles or procedures to get something done or accomplished; Anyone can follow a system.

2.     A ritual is a series of actions or type of behavior regularly and invariably followed by someone.  It’s different from a system.  A system might only be followed once, but by many people. A ritual is something someone or some group does again and again, in the hope of arriving at the same or improved outcome.

3.     A habit is a regular tendency or practice, especially one that is hard to give up.  If you want to be productive, you have to be habitual with your rituals, as part of your system.

How does it all fit together?  Name a system. Next, list the process steps, sequence, and any rules around them. Last, do the steps again and again until it becomes a habit.

Lack of these kills productivity: Clarity, Progress, or Commitment

1.      Clarity is the quality of being certain or definite.  You need clarity in order to know what you need to do. Lack of clarity creates confusion and waste. Each step of a system should be actionable and repeatable. In order to ensure certainty around your steps, write them down; maybe draw a picture or diagram. If your outcomes are not repeatable, you have an experiment but not a system.

2.     Progress is forward or onward movement toward a destination or goal. Your goal is productivity. If you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system.

3.     Lack of commitment to the system results in you no longer using the system. You move on to something new to get the productivity results you seek.

In the event your system lacks clarity, progress, or commitment, performance will go down or you’ll stop using it all together.

Scrum

Enough with the nebuous ideas. Let’s apply the patterns against the Scrum Framework.

scrum productivity patternJeff Sutherland and Ken Schwaber did a pretty darned good job providing clarity around the system in The Scrum Guide.  Being the Guide is only 16 pages long, there it’s a whole lot to it. It includes a definition of Scrum, the theory behind it, and then provides details behind teams, events, and artifacts.  That’s it!  Rituals (events) include sprint planning, a daily (15-minute) Scrum, a sprint review, and a retrospective.  Each of these rituals helps provide both feedback and progress within the sprint.  To ensure we see the progress, we timebox sprints, commit to deliver product increments regularly, and use information radiators like burndown charts to visualize the completion of work.  Like any system, if you are not habitual about each of the items within the Scrum Guide, Scrum falls apart.  That means commit to the system and be consistent, sprint after sprint.

Summary

Though I have only provided one example of the pattern in this post (against Scrum), I’ve also applied it to Kanban and the Pomodoro Technique. Look for future posts on the topic.  Like in Scrum, once your defined system becomes habitual, you can start to focus on improvements. Maybe you want to do more in less time. Maybe you want to do the same with higher quality. You be the judge. It’s your system. Remember, you’ll still need clarity, progress, and commitment or your productivity will be short lived.

Listen to Dave Prior and me in an episode of LeadingAgile Sound Notes, as we talk about the Productivity Triangle.

If you want a copy of the triangle, download it here: Productivity Triangle Template

The post Productivity Patterns appeared first on LeadingAgile.

Categories: Blogs

Do you have the courage to be agile? #sgza

Growing Agile - Tue, 12/13/2016 - 12:37
This was the closing keynote at Scrum Gathering South Africa 2016 (#SGZA) by Gitte Klitgaard. Gitte spoke about being brave, vulnerable, giving trust, being unique and asking for help. We also all got to do the scrum dance! Basically stand up, put your arms out and now spell your name using your bum to move […]
Categories: Companies

Did the math on my contribution to global warming

Henrik Kniberg's blog - Tue, 12/13/2016 - 00:49

I was curious about how many tons of carbon dioxide that my family pumps into the atmosphere (= global warming). Looked at the most direct variables: flying, driving, and home electricity. There are obviously more variables to look at (like beef!), but I’m starting with these three, as the data is readily available and I gotta start somewhere.

Result (updated):

  • Flying = 14.6 tons per year
  • Driving = 4.1 tons per year
  • Electricity = 0.5 tons per year

So, 19 tons of CO2 per year. Damn! Sorry about that, earth and future generations. Good news is that I now know how to reduce it by ALOT (like 5 times less)!

CO2e emission before and after

Here’s what I learned:

  1. I thought electricity consumption would be an important thing to optimize. But it’s NOTHING compared to driving and flying (at least not here in Sweden)! No more bad conscience for forgetting to turn off lights and computers.
  2. BIG aha: Buying a plugin hybrid car will reduce our carbon footprint by at least 3.5 tons per year! Because our driving pattern is almost 100% local (carting kids around to school & activities), we’ll almost never need to burn gasoline. Good, cuz I can’t find a fully electric car that fits our big family comfortably. And our current car is breaking down anyway.
  3. A big part of my flying footprint has been just going back and forth to Billund in Denmark every month or two (working with Lego). But actually, it would take only 9 hours for me to get there by train. Train is basically zero carbon footprint. So if I continue travelling to Billund I’ll probably to do it mostly by train. First class, working along the way. Train = 3 ton reduction per year!
  4. Biofuel is the only effective way of reducing flight emissions (other than not flying of course). Biofuel can reduce aviation CO2 emission by about 80%. That compensation will cost me about 400kr per flight hour via flygreenfund.se. Most of my flights are well-paid business trips to do conference keynotes, so I can definitely afford to pay that. Will do that for all flights from now on. Biofuel compensation = 9 ton reduction per year! I asked flygreenfund.se to invoice me SEK 26,000 today, to cover this year.
  5. I was surprised to learn that the electricity I use is clean (from CO2 perspective). 54% hydro, 45% nuclear, 1% wind. Sweden in general has mostly clean electricity.
  6. Despite (5), I’m exploring options to install solar cells on our property. Might not significantly reduce my carbon footprint, but I see it as more a long-term thing. It’s an investment that hopefully will pay off in 10 years or so, it is a way of supporting clean energy in general, and I will learn things along the way. About 10% of Swedens total energy is imported fossil fuel (roughly – hard to find consistent data about it). The more people who use solar energy at home, the less they use the grid, the less dirty electricity Sweden needs to import, the more clean electricity Sweden can export. Haven’t done the math on that yet though, so no numbers.

These improvements amount to 16 tons less CO2e emission per year, or a 5 times reduction!

So here’s my goal for 2017:

  • Flying = max 3 tons per year
  • Driving = max 1 ton per year
  • Electricity = max 0.5 tons per year

Total: 4.5 tons of CO2, instead of 19! Still not good, but definitely better.

I’m definitely not an expert on these things, but it took just an evening of googling around to learn how to cut my carbon footprint 4-5 times, without any major lifestyle change. Pretty cool!

I made sure to be picky about the sources of data. No reporters, tabloids, or social media bubbles! Checked multiple sources for everything, and fiddled around in a spreadsheet to double-check the math. But do let me know if I’ve got anything badly wrong (and if so, please include references).

Here is the spreadsheet if you are interested. I listed most sources there too.

 

Categories: Blogs

Dealing with Duplication in MediatR Handlers

Jimmy Bogard - Mon, 12/12/2016 - 22:37

We’ve been using MediatR (or some manifestation of it) for a number of years now, and one issue that comes up frequently is “how do I deal with duplication”. In a traditional DDD n-tier architecture, you had:

  • Controller
  • Service
  • Repository
  • Domain

It was rather easy to share logic in a service class for business logic, or a repository for data logic (queries, etc.) When it comes to building apps using CQRS and MediatR, we remove these layer types (Service and Repository) in favor of request/response pairs that line up 1-to-1 with distinct external requests. It’s a variation of the Ports and Adapters pattern from Hexagonal Architecture.

Recently, going through an exercise with a client where we collapsed a large project structure and replaced the layers with commands, queries, and MediatR handlers brought this issue to the forefront. Our approaches for tackling this duplication will highly depend on what the handler is actually doing. As we saw in the previous post on CQRS/MediatR implementation patterns, our handlers can do whatever we like. Stored procedures, event sourcing, anything. Typically my handlers fall in the “procedural C# code” category. I have domain entities, but my handler is just dumb procedural logic.

Starting simple

Regardless of my refactoring approach, I ALWAYS start with the simplest handler that could possibly work. This is the “green” step in TDD’s “Red Green Refactor” step. Create a handler test, get the test to pass in the simplest means possible. This means the pattern I choose is a Transaction Script. Procedural code, the simplest thing possible.

Once I have my handler written and my test passes, then the real fun begins, the Refactor step!

WARNING: Do not skip the refactoring step

At this point, I start with just my handler and the code smells it exhibits. Code smells as a reminder are indication that the code COULD exhibit a problem and MIGHT need refactoring, but is worth a decision to refactor (or not). Typically, I won’t hit duplication code smells at this point, it’ll be just standard code smells like:

  • Large Class
  • Long Method

Those are pretty straightforward refactorings, you can use:

  • Extract Class
  • Extract Subclass
  • Extract Interface
  • Extract Method
  • Replace Method with Method Object
  • Compose Method

I generally start with these to make my handler make more sense, easier to understand and the like. Past that, I start looking at more behavioral smells:

  • Combinatorial Explosion
  • Conditional Complexity
  • Feature Envy
  • Inappropriate Intimacy
  • and finally, Duplicated Code

Because I’m freed of any sort of layer objects, I can choose whatever refactoring makes most sense.

Dealing with Duplication

If I’m in a DDD state of mind, my refactorings in my handlers tend to be as I would have done for years, as I laid out in my (still relevant) blog post on strengthening your domain. But that doesn’t really address duplication.

In my handlers, duplication tends to come in a couple of flavors:

  • Behavioral duplication
  • Data access duplication

Basically, the code duplicated either accesses a DbContext or other ORM thing, or it doesn’t. One approach I’ve seen for either duplication is to have common query/command handlers, so that my handler calls MediatR or some other handler.

I’m not a fan of this approach – it gets quite confusing. Instead, I want MediatR to serve as the outermost window into the actual domain-specific behavior in my application:

Excluding sub-handlers or delegating handlers, where should my logic go? Several options are now available to me:

  • Its own class (named appropriately)
  • Domain service (as was its original purpose in the DDD book)
  • Base handler class
  • Extension method
  • Method on my DbContext
  • Method on my aggregate root/entity

As to which one is most appropriate, it naturally depends on what the duplicated code is actually doing. Common query? Method on the DbContext or an extension method to IQueryable or DbSet. Domain behavior? Method on your domain model or perhaps a domain service. There’s a lot of options here, it really just depends on what’s duplicated and where those duplications lie. If the duplication is within a feature folder, a base handler class for that feature folder would be a good idea.

In the end, I don’t really prefer any approach to the another. There are tradeoffs with any approach, and I try as much as possible to let the nature of the duplication to guide me to the correct solution.

Categories: Blogs

Doneness Focused Processes

NetObjectives - Mon, 12/12/2016 - 21:21
In a previous article, I described the three levels of doneness tests – business, customer/user, and technical.   Corresponding to these levels of tests are three processes that are all focused on the doneness tests.   These are Business Test-Driven Development (BTDD), Acceptance Test-Driven Development (ATDD), and Test-Driven Development (TDD).   We’ll see how they differ and how they all relate...

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