Search the Community
Showing results for tags 'in progress'.
-
User Story Mapping is an excellent way to identify and visualize a skeleton of a software. A User Story Map is basically a customer journey that is used to define functionality in a system. Because this comes from a user perspective it becomes easy for management and business analysts to understand and map out the need they want to see in the system. As such a User Story Map is an excellent tool for business analysis, but it is not suited for requirements because it is focusing on what is visible only to the user. For development as actual user stories to build code towards a User Story M
-
I often see organizations trying to have one approach throughout the organization. It is either based on value streams or it is based on system organization. Neither work very well as a one solution fits all for different reasons. As organizations grow we see larger gaps between management and IT. This increase the need for control and this is why we see more organizations trying to force a value based organization today. You can read more about this in the chapter "The lack of Portfolio management reduce Trust" in the Portfolio Management section of this book. Value Based Organiza
-
As a manager at the production level you are the last checkpoint before the teams. Your job is to organize incoming requests to ensure that the capacity match the requests. Unfortunately these requests usually comes through multiple channels and different means of communication, forcing you to manually trying to organize them in some form of coherent and useful way. Excel is a common tool here as is a high level of stress and that feeling that you have missed something. This is where portfolio management becomes a very handy tool. I call it the funnel of sanity. By directing everyone
-
If you do not have portfolio management then your organization will suffer. There is no way around that because at the end of the day you will need a way to steer the organization based on finance and resources. It is that simple. Without portfolio management you will find yourself trying to implement processes to force control downwards in the organization. You will implement processes where people will need to report progress and different forums to "align" different aspects of the organization. At the end of the day however there will always be things you are unaware of and the cycle o
-
When you write something as complex as this book, then feedback becomes very important. Not only because I am not all knowing, but also because feedback can give new insights and learnings. As someone who always want to learn new things this is a great thing and I see feedback in the form of debates or constructive criticism as a positive thing. So anyone who provide feedback or inspire me with comments, links and research material is a person I consider a Muse. I reward this contribution by giving you a special title of recognition here on the site and I will mention you in the book as
-
If you want to become a Muse, then read this page for more information. These are the people that have inspired and challenged me in my work with this book in no particular order: @johanb - Design and frontend. Johan was one of my first Muses. @Kathy Tavlariou - Ecommerce. Kathy was one of my first Muses.
-
Over the years I have worked with many methodologies and processes and to be honest none of them are inherently bad. I have taken plenty of things from for example ITIL, Scrum and Kanban that I think is very good and that I see people feel that it add value to the way they work. If we are being brutally honest here, then it does not really matter what methodology or process you want to use. The work is always the same. I know every organization always claim to be "unique" and that they need adaptation to whatever they implement, but I say that is a load of crap. The uniqueness has nothing
-
If you plan to implement new ways of working based on this book, then it is important that you understand that change comes with a price tag. I have seen many companies embrace a new way of working only to place the burden of change on the organization. Nonsense catchphrases like "grassroot movement" or "crowd sourced roll out" are usually mixed with ideas like "teach the teachers" and "organic change". These are sure ways to fail to make any substantial change in the organization. Change must come from the top and you need to have a project for implementing change. This is because change
-
To say that there are some overlap and gray areas between requirements and business need is not an understatement. I have met many on both sides that clearly are not working as the role suggest. While this is not optimal in most cases it is not a problem to wear multiple hats, but it will make the work less clear and you are more likely to get burned out due to the workload. This is also a problem with requirements and business need that have a tendency to lead to a situation where you have huge and tiny tasks with various level of refinement all dropping into the development team. This i
-
If you have worked in the consultant business or in a project based workplace you probably have felt the pain of flawed processes. The lack of structure or the confined structures strangling the project all tangled up with a confusion and uncertainty of what is actually expected. Communication issues between management and development teams make development strained at times and you need to work overtime or worse just to show the client or boss that you are taking damage control serious even if it will not solve the issues in the project. I have been in projects sold as fixed price with f
-
During my years as a consultant and owning my own design firm I noticed that many projects failed to deliver on time and/or on budget. Mostly this has nothing to do with the client or the consultant as it is a process problem. This book is an attempt to describe a process that I believe works for large and complex IT projects as this is where I have my experience. This is also where I see that other ways of working fail most. The result as I see it is that projects become more costly and that the people in the project will need to work more than necessary causing stress and sickness
-
In this book I will refer to a few tools that I use to set up this work process. You can of course apply this process to any tool, but I have selected the most common tools that I work with that I feel work well for this purpose.
-
”A requirement is by definition a translation of business need to actionable av verifiable tasks. It is also the legal agreement set between client and supplier on what should be accomplished. ” This means that what is defined in a requirement is what both parties agree should be built. This is rarely the way requirements are written and in many cases it becomes a wishlist from the business side instead of a defined agreement of what is to be built. Even more rare is it to get a definition of the business value of what is to be built and the thoughts behind it. For a requirement to b