#Youtrack est un outil de gestion de #projet qui peut être adapté aux processus de l’entreprise pour l’aider au suivi des projets et des tâches. Vous utilisez les tableaux de méthodologie #Agile, vous planifiez les sprints et les versions, vous maintenez une base de connaissances, travaillez avec des rapports et des tableaux de bord, créez des flux de travail qui suivent vos processus d’affaires ?
#scrum et les mêlées quotidiennes
Dans cet article, Matt, développeur à Los Angeles, s’attaque aux daily #standups, ces réunions de la méthodologie SCRUM, très à la mode actuellement. Sous ce terme se cache une réunion quotidienne d’au plus 15 minutes, se déroulant normalement debout, qui … Lire la suite
How Not To Kill Your Software Project
Tons of software development projects tend to fail after launch for various reasons, of which the primary one is the lack of clear goals. Another almost equally significant but underestimated cause of failure is that a considerable number of these startups were solving the wrong problem.This situation is like a case of going a hundred miles per hour in the wrong direction and is quite common in the software development industry, but often binned under the ‘incompetence’ category (although, admittedly, that does play a role in some cases). It is an issue of poor communication between the parties involved.An ideal project would mean that all the organization’s staff at every level, as well as the target users, would be utterly convinced about the need to product and its ability to solve the (...)
Estimation — how can we estimate with confidence in software delivery?
Estimation — how can we estimate with confidence in software development?Introduction‘When will it be done?’ is one of the most common and difficult questions to answer in software development.Estimating in software is traditionally difficult, inaccurate most of the time, with project teams spending a significant amount of time on the process.There are a number of contributing factors to this. Part of it is that software development is a design activity, and thus hard to plan and estimate. Software is done with people, and it depends which individual people are involved. Individuals are hard to predict and quantify and humans in general are inherently bad at predictions . Those teams that build the software are operating in an ever-changing business and technology landscape.The cost of (...)
How to apply #agile manifesto in your software #development career
If you work in the software development industry, I have no doubt that you’ve heard of Agile manifesto. Unlike the traditional way of…Continue reading on Hacker Noon »
When asked why he robbed banks, Willie Sutton famously responded, “Because that’s where the money is.” Similarly when creating a new product, we focused on enabling transparency, “Because that’s where the opportunity is.”At least, you’d think that’d be the case. Transparency as a concept appears to be widely accepted as a way for teams to be more effective. In fact if you look at the stated values of many newer companies, transparency is typically highlighted, as one of the 4 or 5 key attributes deemed critical to the success of the organization.Transparency just makes things . . . easier.However, we’re finding the day-to-day reality at most organizations is somewhat disconnected from their stated aspirations. I have been puzzled by why this should be the case. Why isn’t transparency more commonly (...)
WIP — Work in… What? | Scrum.orgBy: Peter Götz, Professional Scrum Trainer, Scrum.orgScrum and #kanban are a great combination. With this insight more and more Scrum Teams become aware of terms and phrases used in Kanban. Like ‘WIP’.When I have used this acronym in the past I have read it as ‘work in progress’. In his book ‘The Goal’ Eliyahu M. Goldratt consequently uses ‘work in process’. I realized this but didn’t give it much thought.This week, though, I discussed WIP with a colleague and we talked about the difference of ‘work in progress’ and ‘work in process’. And only then I realized that the two phrases mean something completely different.Work in Progressprogress (n): a forward or onward movement (as to an objective or to a goal)progress (v): 1. to move forward or 2. to develop to a higher, better, (...)
How Kickstarter’s Mark Wunsch Used Engineering #metrics to Make a Case for #refactoring
“Effective engineering leadership is being outcome-oriented,” says Kickstarter’s Mark Wunsch.When Mark first joined Kickstarter as VP of Engineering, one of his first decisions was to re-organize the engineering department, based on business-oriented objectives.Each 3–7 person scrum team focused on a different “essence,” or a different customer-facing part of the product. This helped engineering understand their work from a business perspective. Mark tells us, “The objective is not to ask, ‘Is the code good?’ but to ask ‘Is Kickstarter good?’”The engineers’ perspective, however, was difficult to communicate with leadership.The engineers were constantly bogged down by problems that were invisible to non-technical colleagues, such as legacy code. Kickstarter has been around for about 10 years, so a (...)
Technical Debt & #scrum: Who Is Responsible?
Technical Debt & ScrumTL;DR: Technical Debt & ScrumIf technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximize the value customers derive from the Development Team’s work, and the Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?This post analyzes the situation by going back to first principles, as laid out in the Scrum Guide to answer a simple question: Who is responsible for keeping technical debt at bay in a Scrum Team?What Is Technical Debt?According to (...)
Improving your Definition of #done
By Simon Reindl, Professional #scrum Trainer, Scrum.orgThe purpose of Scrum is to create a potentially releasable Done product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. The technique described here allows for greater transparency on where the Definition of Done is, and what are the next steps.The intent is to provide a structure for the teams to reflect, and then build a plan on what to introduce to improve the quality of their product Increment. This could be run during a Sprint Retrospective, before starting a team, or at any time during a Sprint.Draw three nested triangles on a whiteboard or flip chart, as show in the image below. Label the centre rectangle “Now”, the middle rectangle “Next”, and the outer rectangle “Future”. (...)
Continuous #refactoring — what’s stopping you?
Continuous refactoring — what’s stopping you?Many times over the last twenty years, I’ve had to work on codebases that have made my job difficult and painful. Small codebases, large codebases, small companies, large companies, media companies, tech companies … it keeps following me around. Let’s just call them “messy codebases”. Talking to other developers about this subject always results in people sharing their own experiences, like a kind of therapy session. Google “bad code” and you’ll get back endless results on this topic. So it isn’t just me.When your code looks like this, you know you’re in trouble. Photo by Ashim D’Silva on UnsplashFixing the code doesn’t fix the habitA recent Twitter thread by Sarah Mei got me thinking about why messy code bases are so common. I’ve seen people “fix” a codebase (...)
A stepwise approach to help you define a real MVP — Minimum Viable Product
An 8-Step Approach to Help You Define a Real MVPFrom a problem to a well-defined MVP in 8 steps: understand the problem, your users, the market and your competitors; define your ‘complete product’ as a backlog of product features; assess your features, rank them and select the smaller set that can bring enough value to your early customers; so they are happy enough to stay engaged and promote your product.1. Frame the problemOne of the most important steps in the product development process — is the understanding and proper articulation of the problem. It is a good idea to use a model, a structure to help you formulate the problem with clarity.Start by describing the ideal situation versus the current one, and how certain users are impacted by this gapSupport your problem statement with (...)
#decision-making: The Most Undervalued Skill in Software Engineering
Decision-Making: The Most Undervalued, But Most Important, Skill in Software EngineeringChess, in general, is the process of making decisions (Photo by rawpixel)“The average person makes an eye-popping 35,000 choices per day”It may come as a surprise to many, but the most important skill in software development is not how good your coding skills are or how much you know about machine learning and data science. It’s decision-making!Decisions, DecisionsDid you know that the average person makes 35,000 decisions each day? About 227 of these are on food alone. Our rapid advancement of technology has us continuously surrounded with an overwhelming amount of information. If that’s not enough, we’re also bombarded with “smart” notifications.Software Development & DecisionsWhat does this have to (...)
The Minimum Viable Product, explained.
What an MVP really is and how you can benefit from it.The term MVP was coined and defined by Frank Robinson and popularized by Steve Blank and Eric Ries. A popular definition is the following:“… the minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future development…”If you analyse this definition, you will see three major components there:1. An MVP provides ‘Just enough features’Assuming you have a product backlog — a list of all the features you want to build in your product — you have to decide the order to build them and when to release your product. The idea is to prioritize the features and release a smaller instance of my product, faster. But what would be the criteria for the prioritization? And how many of the top (...)
The Product Owner — #scrum’s Great Success and Failure
The Product Owner — Scrum’s great Success and FailureYou don’t have to have a “Product Owner” to be AgileThere’s a complaint about #agile development which is: “Scrum is so well known and so widely used, that people often mistake Scrum for Agile development.” It’s a fair criticism. The prime example of this is the “Product Owner” role. The Product Owner role (as far as I know) comes from Scrum. The role aims to satisfy this Agile principle:“Close, daily cooperation between business people and developers.”Pretty much all software development companies want to be Agile now and it seems like setting up “Product Owner” positions is standard as part of that process. The problem with that is that the role gets anchored to the Scrum definition of “Product Owner”. While that solves some problems it raises other (...)
Break Down Silos! How to Enhance User-Centricity on #scrum Teams
Gary Pedretti, Professional Scrum Trainer, Scrum.orgI often see User Experience (UX) Designers struggle to align focus, work, and approach with Scrum Teams building increments of product in iterations of 30 days or fewer. Common concerns and questions I hear include:“Developers aren’t really interested in the user, they just want to build.”“I’m trying to work side-by-side with the team, but I’m always a bit ahead of them, so what should we talk about in our Daily Scrum?”“I don’t work in sort cycles, or tactically. My work is strategic.”“Why don’t developers use my design artifacts and decisions? Why do they never go back and refactor for good design? Why do I feel like I never have any influence?!?!”These challenges often result in tenuous relationships between UX Designers (UXDs) and Scrum Teams — (...)
Startups and the Importance of #agile Product Development
Product development is of critical importance for #technology startups: given the limited budget typically available to early-stage startups, making the right product development decisions can make the difference between success and failureIn a report* by CBInsights, failure reasons such as ‘Non-friendly product’ and ‘Product without a business model’ feature at the top of the list. According to the same source, 42% of the startups analyzed, stated that there was ‘no market need’ for their product, while 17% delivered ‘a non-user-friendly product’.Other reports, articles and blogs from #startup founders, seem to agree that most of the major failure factors are strongly connected to product management.Product-related startup risksProduct-related risks could refer to both the definition and the (...)
4 Myths About Programmer Motivation
I’m just not motivated to code today.Myth #1: Managers cannot (or should not) affect motivationWhen managers believe that people either have or do not have motivation, they feel powerless to affect motivation. In her book Mindset, Dr. Carol Dweck refers to this as the “fixed” mindset. The fixed mindset is the belief that people are born with unchangeable strengths and weaknesses and that people would do well to build on their strengths and avoid tasks at which they are weak. She contrasts this with the “growth” mindset, which is the belief that people grow and learn throughout their lives.In Mindset, Dweck explains how to break out of the fixed mindset and adopt the growth mindset. She also provides research supporting the belief that this change is possible (even for old guys like me!). But (...)
#strategy and Agility: Lessons from #toyota, Honda, Yamaha, and #tesla
A great example of strategy tightly coupled with agility/fast-product-feedback-loops: Toyota and the Toyota Production SystemThe aim of the Toyota Production System (“TPS”) is “making the vehicles ordered by customers in the quickest and most efficient way, in order to deliver the vehicles as quickly as possible” (emphasis is mine).In other words, the TPS is the mechanism that Toyota uses to build a lean / #agile / high mobility mentality into its production lifecycle from order to delivery. The TPS supports Toyota’s overall strategy of building the most reliable and lowest total-cost-of-ownership cars in the world.All workers are obligated to improve any process they can to improve speed and reduce waste in the production line. They’re not just permitted to improve, but obligated… in other (...)
Essential Reading List for Enterprise Software Developers and Architects
The target audience for this reading list is enterprise software developers and architects. I chose to focus on system design, data modelling, security, devops, process, creativity, and computer science foundations which are essential and generally useful to most software engineers. Enjoy, happy reading, and let me know what you think!Code Complete by Steve McConnell — This comprehensive, classic tome on software design, construction, and craftsmanship has stood the test of time. McConnell’s discussion of metaphors, #architecture, debugging, quality assurance and ethics are excellent and still relevant in the context of the cloud, troubleshooting complex systems, fixing security defects, and collaborating with diverse teams. My favorite proverb therein is: measure twice, cut once. Visit the (...)
Understanding Micro Frontends
As a #frontend developer, all these years you were developing monoliths, even though you already knew it was a bad practice. You divided your code into components, used require or import and defined npm packages in your package.json or mounted sub git repositories into your project, yet you ended up building a monolith. It’s time to change it.Why is your code is a monolith?All frontend applications are a monolithic application in nature, except apps that already implemented micro frontends. The reason is if you are developing with the React library and if you have two teams both should be using the same React library and both teams should be in sync on deployments and always will be conflicting during code merges. They are not separated completely and most probably they are maintaining (...)
Estimating #agile Projects with User Stories
How to Estimate anAgile Project With User StoriesEstimating software projects is hard. Early on in the development process, you can’t precisely define the scope of a project. Because inevitably, the scope will change after development kicks off, since the team will have learned more about the project and its context by then. Still, teams have to estimate the resources they need for a project, at least approximately, before getting started.So, how should you tackle this, then?The traditional approach is to enter an analysis phase where you create a detailed specification of what needs to be built. But like we said, the scope of a project isn’t exactly clear before development begins. For that reason, analysis isn’t the best approach.What is a user story?Simple but powerful, a user story is a (...)