AgileSparks-Agile Consulting/Training With a Spark.+Add.Feed Info1000FOLLOWERS
AgileSparks is providing Agile/Scrum/Kanban solutions including training, coaching, assessment, All things Agile/Lean,focused on Agile Transformations, Scaling, Organizational Agility, Agile Marketing, DevOps, Kanban, Lean Startup.Follow this blog to know more about Agile.
The Email Inbox – The real Personal Kanban frontier
I’ve been struggling for years with visualizing my personal work using Kanban.
Using a physical board isn’t that practical since a lot of the time I actually do my work I’m not at my office.
I then tried Kanban tools such as LeanKit, Trello (and even AgileZen…). This worked pretty well for a while, but I kept falling out of it. Something was missing.
Over time I realized that it relates to where so much of the work happens – in my email inbox. The overhead of creating Kanban cards based on emails I’m receiving and of syncing progress on the Kanban board to what’s going on in email proved to be too much of a bother for me. Maybe I’m not disciplined enough…
Then, a couple of months ago, Flow-e arrived on the Kanban tools scene. It seems like it’s built with people like me in mind. It provides Kanban-based flow visualization and management that’s tightly integrated into your email inbox.
I’m still learning and experimenting with how to integrate flow-e into my daily routine. From a user experience perspective, it’s doing exactly what I always wanted. It provides your email inbox as a backlog/queue to the left of your Kanban board and you can easily process your inbox and pull things into relevant work stages that you personalize.
Flow-e in action
It actually works beautifully. Setting it up to connect to my AgileSparks Google Apps account was a breeze. It smartly by default only loads the last 2 weeks into the “inbox” area which keeps you focused and keeps the app light and fast. You can easily configure your workflow. Here’s what I currently use:
Cards can originate from emails or you can just create them on your own. Threading is supported well. New email on a thread is very easily associated with an existing thread/card that’s already in progress.
You can easily perform typical email actions such as replying, forwarding, archiving, postponing, all within the Kanban board.
When it comes to mobile, I haven’t yet found a full kanban view. It does have a thoughtful responsive web design that allows you to process the inbox. This makes sense to me. I won’t necessarily manage my kanban on my phone but I definitely process my inbox on it. Having the option to do it directly in Flow-e reduces the risk that I’ll forget about it and just use google inbox directly.
Aging/SLA information – I coach teams to look for cards that are aging too much in their process and see how they can help them flow. This is important in personal Kanban as well. Both for cards that originate from emails as well as cards created manually. (This is actually a power-up that the Flow-e team is considering…)
Analytics/Metrics like cycle times, CFDs, and some other insights that can help me improve my flow. The added benefit of having this apply to my email inbox can make for an awesome combination.
Even better integration with inbox actions such as reminders, pinning, snoozing. Ideally, these actions should map to some action on your Kanban board. E.g. move something to my “Ready/Next” queue when I pin it. Move it to “Later” when I snooze it. Add a “due date” according to the time I snooze it for maybe? Or maybe add it as a “start date”. This will help people like me that WILL do some work directly in their inbox by mapping these inbox actions to an appropriate kanban/flow visualization.
The bigger picture
From a change management perspective, with Flow-e it’s now easy and natural to start experiencing Kanban at a personal level, with the hope that it will be a “gateway drug” to team/enterprise-level Kanban, which we know is a “gateway drug” towards other agile practices and behaviors. I’m already thinking about how we could leverage Flow-e as part of the AgileSparks Way. Maybe get leaders in the organization to start using Personal Kanban as part of learning about Flow, Kanban and agility…
“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.” – W. Edwards Deming.
A big number of bugs that is discovered in testing processes is easy to prevent. The fact that such bugs are discovered at the testing stage, which is usually at the end of the process, shows that the developers did not perform primary quality check of their work. This wastes the time of both testers and developers, reduces motivation and efficiency and slows development. The costs go up significantly as a bug moves through traditional SDLC. For example, IBM estimates that if a bug costs $100 to fix in Gathering Requirements phase, it would be $1,500 in QA testing phase, and $10,000 once in Production.
While we can’t expect to test everything and go our entire lives deploying a product that’s 100% error free, we can make strides to safeguard software as best we can. Built-In Quality is a core principle of the Lean-Agile mindset. It helps avoid the cost of delays associated with the recall, rework, and defect fixing. The Built-In Quality philosophy applies Systems Thinking to optimize the system, ensuring a fast flow across the entire value stream, and makes quality everyone’s job. Built-In Quality practices ensure that each solution element, at every increment, meets appropriate quality standards throughout development.
One way to drive forward Built-In Quality is to adopt the Zero Bugs approach.
Without Zero Bugs approach, you typically have the overhead and increasing cost of fix, as well as a culture in which people are used to bugs being a standard part of their environment which only makes the backlog of bugs grow (the broken window theory).
Zero Bugs Approach means applying a policy where the team keeps a very low (optimally zero) threshold of open bugs. Once the threshold is reached, the team “Stops the line” and fixes the bug(s). Developers and Testers are pairing and therefore part of the bugs isn’t even reported in the bugs management tool and is fixed immediately. There is no Severity indication as a bug is a bug. Once you implement the Zero Bugs approach, you will no longer have to manage and prioritize a never ending backlog of bugs.
Progression bugs, which are related to new functionality, are fixed immediately as part of the Story Definition of Done. Regression bugs are negotiated with the Product Owner who decides whether to fix the issue or to obsolete it. If the fix doesn’t risk the iteration, the bug will be fixed immediately. If it might risk the iteration, then the PO prioritizes the bug vs. the team’s backlog, and the bug will be fixed at the latest as top priority of the next iteration.
The Zero Bugs approach is just one of many ways to install a Built-In Quality culture and to shift left the quality awareness.
AgileSparks offers a 1-day Built In Quality course for tech leads that covers how leading software companies are changing their approach to quality, in order to achieve speed and continuous delivery. This course pushes the boundaries of the quality mindset and challenges the thinking about quality ownership within the team.
I’ve been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …)
The first step is to understand that for a new product there is a unique value proposition hypothesis. This is the area where your product/service will be unique.
The next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of “Table stakes” features just to make sure it is “Viable” as a product.
Your MVP is also a hypothesis. It might be good enough to find Product Market Fit or not. The case where each potential customer you engage tells you “This is great but in order for me to use it I need X” and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet.
If on the other hand you are seeing more and more answers pointing to the SAME X then it makes sense to revise your Customer/Problem/Solution Hypothesis.
You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP.
Let’s say MVP2 is successful and you are seeing real traction of early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopters crowd. Based on feedback you’ve been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them, by the way, extend your unique value proposition and some of them make your current product more robust.
In the case of areas with a strong indication of value, you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The aim of the MMF is to bring in value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped you feel comfortable working on the next MMF in that area. If on the other hand, you want to wait and see if your first MMF sticks…
…then you are back in hypothesis land. But now your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a “pioneering” feature – the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers.
If you learn that the MVF has hit gold you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point look for alternative growth path. Essentially the MVF is a mini-me version of the MVP.
There you have it. The full model. Essentially my point is that you grow a product in uncertain markets by attempting various MVPs. Then once you achieve Product-Market Fit you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on.
While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective.
The dinosaur carpaccio now comes in as slicing each of those pieces here to smaller slices aimed at reducing execution/technology risk. (typically these are called User Stories) Those smaller slices might have tangible business value but on the other hand, some might not. It is more important for them to provide early implementation decision feedback along the way.
Feel free to use this model. Let me know what you think about it and how I can improve it!
Values and principles can often seem lofty and intangible so many agile practitioners prefer to focus on tools and practices. That’s understandable but unfortunate. Because values and principles have the potential to provide us with clarity and guidance that transcends what practices and frameworks can achieve. Ideally – part of your empiric inspection and adaptation process should explore whether you are living according to your values/principles. To achieve that you can try a value-based retrospective.
Values-based Retrospective – The TL;DR (Too long; Didn’t Read) version:
Create a matrix of your values as rows, and some classic retro categories such as plus/delta as columns. Then run a “generate insights” activity in which you try to see what you’re doing that upholds a value or flies in the face of it and could be improved. Afterwards continue the retrospective as usual by deciding what to focus on, getting to the root cause, coming up with experiments and committing to some change.
The Value of a Values-based Retrospective
This can help in a couple of ways:
Refresh the team’s recollection and understanding of the values/principles and their importance
Help you identify espoused values that you need to work on a bit (or a lot…)
Celebrate some values that are coherent with your actual behavior.
Identify impediments that are in your way to actually behaving in a way that’s aligned with your espoused values.
Choosing Values to Focus On
One question you should probably be asking is “What values should I use?”
Your organizational/team values (assuming those are ones you feel are real and relevant – not just posters on the wall…)
Decision filters like the Lean Decision Filter– in this case, your values will be Value, Flow, Eliminate Waste or the Agile Decision Filter – in which the values would be “making progress with imperfect information”, “treating WIP as a liability”, “encouraging a high-trust culture”
Scrum Values Retrospective
Regardless of what set of values you choose – make sure you understand the value of each value. E.g. how does the Scrum value “Courage” benefit you as a team? Why is it required in order to achieve high-performance? This can be a warm-up activity of the retrospective – each person trying to lay out his perspective on this and then sharing notes.
Improve Collaboratively Using Models
You could also use this retrospective style to bring in sets of values as models to look at while trying to improve. What I mean by that is you could run a retrospective using a certain set of values even if they’re not formally your values. For example, Even if you’re not doing Scrum, running a retrospective using the Scrum Values would be educational, would probably inspire some interesting discussions, and drive some useful experiments.
In summary – running a values-based retrospective can be a great way to run a different style of retrospective – one that is one hand focusing on the roots of what we’re trying to do and on the other hand grounded in our actual behaviors and what to do about them.
I love this representation by Ahmad Sidky in his talk at Agile NewZeeland 2015, describing the elements of organizational culture and how Agile transformations influence them.
Transformations naturally start with a change in the process and the tools, which inevitably create tension that is supposed to catalyze a deeper change in other elements of the culture. Many implementations struggle and even get stuck at that stage.This is the hard part, since it is mostly about people behaviours and habits and it takes time. This is exactly where HR professionals come in! I’m not trying to say that only at this stage HR people start partnering and pushing the transformation, I am only emphasizing their importance at this stage. HR departments are key in leading Agile transformations to long, lasting and truly impactful ones.
Speed is the “holy grail” of Agile. Strangely, it isn’t only about implementing some new technologies that help building software faster. It also and mainly includes changing basic paradigms that lie at the core of the organizational culture.
Here are some aspects and examples that are part of HR responsibilities and activities that can push new paradigms into the organizational culture:
Helping leaders with leading and shaping the change process and providing them with the tools to lead & coach in a way that grows teams’ autonomy, mastery and purpose. Agile frameworks are built to enable it and it’s imperative to understand how to harness them effectively. The role of the manager is highly impacted from the transformation to Agile and as the managers are critical to the organization leaving them confused is a terrible lost.
Leading the change in a way that engages people is crucial- sometimes a small mistake here can harm the transformation and take it many steps backwards. The change itself requires constant inspecting and adapting, and through this practice, Agile ways of thinking are injected into the way the organization operates. The hardest challenge of Agility is collaboration across silos. HR people have this wide system view across silos, and can help steer the change.
Organizational restructuring – Agile transformation is not a one time change. The organization evolves and might have several structural changes that bring it closer to a value-driven Agile organization. People have new roles and responsibilities, new tools and practices they need to master. With Agile comes flexibility in terms of roles and responsibilities and it’s HR’s mission to define the structure of these new, flexible roles and responsibilities and to address any problems employees have during the transition.
Creating collaborative work spaces: Agile team members need to be highly collaborative in their day-to-day work. HR can help create an open work space where people can freely communicate to enhance this collaboration.
Recruiting people that have the right mindset and attitude to work in an Agile environment is key. Some example characteristics: team players, T-shaped people – people that can contribute in areas that are not only in their main skill.have experience working in an Agile environment.
Performance reviews influence people that understand which behaviours are appreciated in the organization. Therefore HR should stress aspects that encourage teamwork, continuous learning and early constructive feedback, self management and taking ownership.
People Engagement – very central to the Agile mindset is the engagement model. HR should help building employees’ intrinsic motivation, creating an environment where people can influence, lead and take ownership. Bringing people closer to value creation.
The 11th State of agile survey published this year keep showing, as every year, that the main challenge for adopting Agile is organizational philosophy and culture. When those are at odds with Agile core values Agility is impeded.
HR professionals “own the keys” to the organizational culture and are therefore critical strategic partners in the transformation.
When we talk about the benefits of working with small batches we talk about risk reduction, about improving flow and getting quick feedback.
I call these reasons “scientific”.
I believe that the main reason for working in small batches is getting things done. The value of getting things done is mainly a moralistic one. It is good to get things done – it does good to your soul.
This leads us to the dark side of working small batches – the addiction.
I see many organizations where people are addicted to getting things done very quickly: fixing defects, making small changes, drowning in many little things, all the time looking one sprint forward, in the good case. Many things are getting done all the time but the work is mainly reactive and not proactive. All the “big projects” – items that will bring great user value or improve infrastructure, are stuck somewhere in the pipeline.
What can they do about it? Can they muster enough patience to work on something big? It is very difficult.
The thing to do is to take the big change and slice it down to small chunks with enough value. Small enough to not require too much patience from the organization and with enough value to provide that feeling of “getting it done” like other day to day items provide. Like other stuff, every small chunk should be deployed – that’s what will make it the real thing.
Slicing big items is a challenge at the beginning but practice makes it quite straight forward. Don’t let the size of things stop you from getting them done.
The kanban method is built around improving the flow of product development. It works very well when you work according to priority. It also works well when some items have schedule constraints. When many items have schedule constraints this becomes an issue.
I was having a discussion with one of my clients and they raised the issue that what’s going on wasn’t clear. Immediately I thought of setting up a kanban board. However when we started to do that it became clear that the main issue is how to commit to clients about deliveries.
Deliveries to my client’s clients include installation of software, configuration, training and beta testing. As a matter of fact my client was managing many small projects and they needed to commit on the various due dates.
In a Utopian world, my client’s clients would all be agile and due dates were less of an issue, however this was not the case, so we needed to come up with some solution.
After some discussion we came up with a scheme for visualizing my clients’ commitments. We call it a Forward Looking Kanban. You can see it at the top of the post.
How Does it Work?
This is a Kanban board (remember that “Kanban” means “signal card” in Japanese) showing what we plan to do in each month. Each column represents a month. The idea is to constantly look several months ahead (this means that when we move to a new month we need to add another month/remove an old month).
Each row represents a main step in the process, maybe like we would do on a regular kanban board, but I believe it should be less detailed.
Each card, like cards on a regular kanban board, shows something we are doing. The main difference here is that the same card may appear in several places on the board. For example we can see that Feature A appears under “Dev” in October and under “Deploy” in November.
Another thing to notice is that each cell contains a WIP limit (well actually, it is more a PW – Planned Work limit, but I’ll leave that at WIP to make it simple). This is critical to the success of this kanban board. The main use of this board is that when something comes up we can try to schedule it, according to available capacity in the various cells. If there’s no capacity we may try to move some things.
My client decided to add a red point to a card each time it is moved from cell to cell to get indication of things that are getting postponed all the time.
It should be noted that WIP limits may be different in different rows: in the example above the first row limits the number of deployments per month, while the development row has WIP limits manifested in points.
The initial WIP limit should take into account both future events and buffers for changes. In the example above December has lower values (due to holidays). The buffers are not shown here but the people working with this board should know not to use the entire capacity of January when we are in September – that is a promise that will not hold.
The client decided that at this stage we will not build an additional kanban board (the regular one). We will indicate whether items are done or not directly on this board.
It’s been some time that I’ve been hearing clients raise issues about making commitments with a kanban board. There are solutions: indicating the date on the card, using lead time to estimate when items will be done. However I hope this scheme I described here will bring a more comprehensive solution.
More and more Marketing organizations realize they need to be faster, more flexible/responsive and more collaborative to have a real impact on the business they’re supporting. More and more marketing leaders believe Agile Marketing is the way to modernize their organization. Scaled Agile Marketing talks about applying Agile Marketing principles beyond one team and beyond the green fields of the unicorn internet company – in larger marketing organizations which face barriers like marketing to businesses rather than consumers and working not just in the online/digital realm but also the physical world.
Inspired by Agile Development, Agile Marketing describes a mindset of continuous learning and validation, customer-focused collaboration across functional silos, adaptive and iterative campaigns and more responsive/continuous planning. Similar to development organizations, Agile Marketing teams use techniques such as Scrum to work in an iterative cadence and Kanban to visualize and improve the flow of work.
Most of the agile values, principles, and practices map pretty well to the world of Marketers. Modifications to the language and choice of practices are needed. Agile Marketing has been growing in popularity in recent years. Larger and larger organizations are now trying to apply Agile Marketing and are looking for a scalable approach.
For medium/large marketing organizations looking to improve their agility this series explores: