How to defeat feature gluttony
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 133 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/48803 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Electronic mailing listLevel (video gaming)Kolmogorov complexityInclusion mapProduct (business)Point (geometry)Software developerAnnihilator (ring theory)Electronic mailing listUsabilityBitFamilyPerspective (visual)Data conversionCartesian coordinate systemRight angleObservational studyEmailJSONXMLUMLComputer animation
01:51
Software developerProduct (business)MathematicsSoftwareVideo gameCartesian coordinate systemEmailMereologyRight anglePerspective (visual)TwitterProjective planeMultiplicationValidity (statistics)Strategy gameContext awarenessBitData managementCASE <Informatik>Multiplication signSoftware testingComplex (psychology)LaptopArc (geometry)Student's t-testAddress spaceComputer animation
05:04
Software developerAbstractionRight angleINTEGRALSoftwareProcess (computing)Data structureMathematicsReal numberPhysical systemSpreadsheetEmailMoment (mathematics)Video gameData miningCartesian coordinate systemReduction of orderSource codeComputer animation
07:48
Software developerPhysical systemVideoconferencingProduct (business)Different (Kate Ryan album)Cartesian coordinate systemOperator (mathematics)Revision controlControl flowOrder (biology)Web 2.0SoftwareSoftware developerAxiom of choiceMathematicsStaff (military)Process (computing)TwitterNetwork topologyCode1 (number)Integrated development environmentChemical equationLecture/ConferenceComputer animation
10:42
Software developerMobile appProduct (business)GoogolTime zoneSound effectProjective planeProduct (business)Complex (psychology)SurfaceCartesian coordinate systemService (economics)Order (biology)Module (mathematics)Physical lawStaff (military)Computer animation
11:53
Software developerAiry functionSign (mathematics)Complex (psychology)NumberVideo gameStaff (military)CASE <Informatik>Cartesian coordinate systemCodeGame theoryCommitment schemeWordLevel (video gaming)Electronic mailing listWeb pageReading (process)Point (geometry)Software maintenanceComputer animationDiagram
13:37
Software developerCommitment schemeWordCartesian coordinate systemMathematicsFingerprintSoftwarePlanningElectronic mailing listLoginScheduling (computing)DemonGodProcess (computing)ReliefSymbol tableMultiplication signPiPhysical lawGame theoryDisk read-and-write headComputer animation
16:18
Software developerFingerprintCuboidMultiplication signCartesian coordinate systemKanban <Informatik>Figurate numberSoftware developerControl flowSpreadsheetBasis <Mathematik>Validity (statistics)Perspective (visual)TowerLevel (video gaming)Metropolitan area networkStaff (military)CASE <Informatik>Computer animation
19:23
Software developerMaxima and minimaReading (process)Context awarenessSummierbarkeitPhysical systemCodeSoftware testingBitMechanism designMathematicsMereologyCartesian coordinate systemDescriptive statisticsSoftware developerDiagramElectronic program guideVideo gameComplex (psychology)Computer animation
21:12
Mobile appSoftware developerState of matterData typeComputer-assisted translationCodeComplex (psychology)Cartesian coordinate systemPerspective (visual)Goodness of fitPhysical systemEndliche ModelltheorieSoftware developerCommitment schemeError messageMereologyRight angleComputer animation
22:21
Dean numberSoftware developerBitEstimatorRule of inferencePoint (geometry)System callComputer animation
23:17
Software developerTerm (mathematics)SpreadsheetEstimatorNetwork topologyMultiplication signPrice indexCartesian coordinate systemOcean currentCuboidNumberInstant MessagingShape (magazine)Mobile appLine (geometry)Different (Kate Ryan album)BitData conversionBranch (computer science)Module (mathematics)Category of beingPoint (geometry)Order (biology)Product (business)Lattice (order)FingerprintInformation securityLoginElectronic mailing listSystem callGroup actionSoftware developerGame theoryCommitment schemeLinearizationData managementProjective planeInclusion mapSoftwareArithmetic meanGodHand fanCellular automatonComplex (psychology)Perspective (visual)Staff (military)Data miningProcess (computing)RhombusRight angleGenetic programmingMessage passingKey (cryptography)Operator (mathematics)PlanningCASE <Informatik>Level (video gaming)ExistenceGoodness of fitMilitary baseRoboticsMathematicsComputer animation
31:18
Software developerNetwork topologyMultiplication signRight angleData conversionEstimatorPulse (signal processing)Arithmetic meanMereologyOcean current1 (number)Point (geometry)Computer animation
32:06
Software developerUsabilityNetwork topologyElectronic mailing listLevel (video gaming)Cartesian coordinate systemSoftware developerLine (geometry)Standard deviationMassSearch engine (computing)Context awarenessComputer animation
33:32
Software developerMaxima and minimaLoginVariable (mathematics)Information securityProduct (business)Staff (military)Physical lawElectronic program guidePerspective (visual)Network topologyFormal language
34:39
Software developerNetwork topologyMetric systemHypothesisLevel (video gaming)Lattice (order)Mobile appContext awarenessEstimatorCartesian coordinate systemPoint (geometry)FingerprintConnected spacePattern recognitionNumberAxiom of choiceTable (information)Perspective (visual)Decision theoryNeuroinformatikFocus (optics)DatabaseSubsetAdditionLoginBitBookmark (World Wide Web)CASE <Informatik>Basis <Mathematik>PasswordGraph coloringComplex (psychology)WordSound effectCoefficient of determinationStaff (military)2 (number)Parameter (computer programming)Letterpress printingComputer-assisted translationFigurate numberMultiplication signProcess (computing)Parity (mathematics)Data storage deviceTape driveMenu (computing)BackupAreaComputer animation
43:50
ArchitectureFingerprintCausalityBuildingCAN busSoftware developerSoftwareStaff (military)GodMereologyLine (geometry)Point (geometry)INTEGRALBit rateCartesian coordinate systemPerspective (visual)Complex (psychology)Data conversionPresentation of a groupPower (physics)Metric systemCellular automatonContinuous integrationProduct (business)CausalityDemo (music)Computer animationEngineering drawing
47:39
Software developerSoftware testingLevel (video gaming)SoftwareNetwork topologyMathematicsMetropolitan area networkMultiplication signLattice (order)FrequencyIntegrated development environmentStaff (military)MereologyInformation securityTheory of relativityData storage deviceMeasurementContext awarenessCartesian coordinate systemVector potentialTraffic reportingEvent horizonGreatest elementLinear regressionCodeComputer animation
51:07
Mobile appSoftware developerState of matterComplex (psychology)Product (business)Task (computing)AdditionMetropolitan area networkSoftware testingSoftware developerCommitment schemeOrder (biology)Staff (military)NumberContent (media)Online helpLevel (video gaming)Cartesian coordinate systemEstimatorNetwork topologyPressureObservational studyNonlinear systemContext awarenessComputer animation
52:22
Software developerCartesian coordinate systemPresentation of a groupNumberAdditionArithmetic meanExterior algebraFigurate numberGoodness of fitCausalityMeeting/InterviewComputer animation
Transcript: English(auto-generated)
00:06
Today, we will be speaking a bit or actually a lot about the requirements. So I wanted to start from small joke around our customers or our business people or our marketing people or however we are cooperating with because usually they want more and
00:25
more and more. And that's why we have the growing list of the features and obviously the last and the most important one is make it like user friendly or basically make it usable. So this I hope will be really exciting.
00:41
So my name is Kasia Mroftsa and I'll be your host today and we'll be talking about feature gluttony. So what feature gluttony basically is is kind of a carving that we want more and more features and probably in our industry it's kind of common theme that we would like to have everything at least from our business partner's perspective and it's not necessarily
01:06
that easy. So this will be the main topic of our conversation and also I try to show you why it's actually bad because you can think business people give us money so if they want more features
01:20
and they are willing to pay for that ridiculous amount of money then maybe it's fine, right? So we'll try to figure it out if it's right or not really and also we try to figure it out how to manage requirements in a way that simply it's easier for us to develop the application.
01:40
The application is stable and it's not too big as well. So hope to give you some kind of the remedies and takeaways that you can then apply at your daily work. So who I am? As I said, my name is Kasia. Here you have my blog, my Twitter handle. If you have any questions, feel free to write email to me or tweets.
02:04
So maybe here I post how many of you have Twitter accounts. Okay, so feel free to make pictures and tweets from this talk. People who don't have a Twitter account also you can, as I said, reach me by email. So I'm part of the Agilent Europe community.
02:22
I also organize the conferences like Agilent Europe Krakow and also I was, when I was in Krakow, part of a community called Agilent Enthusiasts Krakow. Right now I'm based in London and my, let's say, employment history was quite diverse.
02:44
I worked in internal IT department as well as in software house. So I have like two kind of perspectives. Obviously, if you are like in internal IT department, your business or your customers are quite easy to reach. You can meet them on the like morning coffee and they obviously can ask you, oh, could
03:04
you add some small feature for me? You know, no one will notice and my life will be easier, right? And then we have a lot of like unstructured changes in our application. On the other hand, you can have like software house that builds a really huge software
03:20
when there's like multiple customers, marketing team, maybe some kind of product owners and lot of like strategy people who are like thinking, okay, what should be in the application? But in both situations we have the lot of features that basically needs to have
03:41
like validation if we really need them or not, but we'll talk through it as well. Currently, as I said, I'm based in London, I'm consultant, so I should actually start from saying it depends and today I'll try to go through this it depends and show you the solution depending on the situation because remember, context is the king.
04:03
Okay, so you know a bit about me, I would like to know a bit about you. How many of you are developers? Okay, are there any testers? No testers, UX designers? Two, okay, two and a half, okay.
04:23
Project managers, product owners? Okay, few, okay, nice. Excellent, and how many of you works in startups? Okay, few. And corporations like big companies employing more than, okay, few.
04:47
And what, and the rest is like students? No? Okay, so like small companies like up to 100 people? Okay, so the rest, okay, cool.
05:01
So I know the range, that's good. Okay, let's start from the gluttony. So what the gluttony is? As I said, it's a carving for more, more, and more. And sometimes we see the comics like the one I presented before from Dilbert and we think, okay, it's only like kind of abstract thing, so in reality it doesn't work like that, right?
05:26
Unfortunately, all the jokes have some kind of their source in real life. So the same is with joking about the overweighted systems and want more and more.
05:41
And basically why our customers want more? By customer I mean all the business people that we are working with if we are like internal IT department or our customers who actually buy software from us no matter if we are like a big software house or a startup. So basically there are like few reasons.
06:02
So basically they can't do their daily job, so they need some kind of work around. And because they think, okay, my work around is the best way to do things, they also want new feature. Okay, could you add me this beautiful spreadsheet integration because that's, you know, it's the way to go, you know, Excel-based software, great.
06:26
So what else? Maybe the business process itself is kind of too big and too complex to handle by users, so also they try to figure it out how to do it in the software instead of thinking how we can simplify business process.
06:42
And here I have example from one of my companies I worked in. We had a process that took 35 days and by just reducing the process and then developing application on top of that we reduced it to five days. And it was like really significant change and simplification of life
07:03
of people who previously did a lot of copy-pasting. So by thinking, okay, how can we reduce spreadsheet integrations, copy-pasting, manual work and basically sending emails and having everything in email not in a structured way in application, you can shorten stuff.
07:24
So this is one thing that we should consider. Sometimes our customers are simply so pleased by features that we are delivering, they start to think, okay, what more we can have inside, it's so brilliant already so maybe we can add more and more.
07:40
So we can see the justification why we want more, it's quite different. Okay, but what can happen if we have system that is like, you know, overweighted so it has like a lot of features? This is really crucial video so pay attention.
08:08
Yes, so some systems even though they have a lot of features, they can handle and they are like not breaking. Some systems have a lot of features and then we are asked to add
08:21
one more feature and then, yes, collapse. It's a lot of problem mainly for operation people who basically need to deal with when the production breaks but also for developers, for everyone involved in the process of doing software because that means that we cannot react to changes
08:43
that are in the outside environment of the company because we have to remember that once we implement some features five years ago, they may be not relevant anymore. So maybe instead of keeping them, we should like remove them and add new but still have some kind of balance
09:00
instead of only adding on top like thinking how we can do stuff. And also especially in ERP systems when you have like multiple customers, we also need to think how to not duplicate the features. Again, I work in a company where we had the three features that did exactly the same thing but in different order.
09:21
As you can imagine, it's a nightmare to have this kind of thing in the code and then remember which customer had which version, how to update that. So it's kind of tricky. Here we can argue, okay, but if customers want it in a certain order, they should get it, right? But if we know that we have multiple customers
09:42
and there will be customizations, maybe we should think how to make the one feature that is configurable so we can change the journey in a way that it's still like one, not several ones depending on the version of the application because then branching is the nightmare. But this is majority of the developers so you probably know.
10:03
Again, we can argue if we have the web tool, that we have the million of users and we don't like the UI or we don't like the features because they were like freshly added, so let's say we have Gmail example. Actually, this is from the discussion on Twitter yesterday. So Twitter is useful for those people who don't have
10:22
worth to install sometimes. So basically, users may be not really satisfied with the change but again, there is a question, the bigger business question, how we would like to maintain two version of the application and if it make any sense because it might make but well.
10:41
Okay, so quickly just to recap what we were talking about and walk through what are the reasons and how the feature Gluttony so we want like more and more affect the product. So first of all, simplicity. It's like really hard to achieve like nice UI
11:03
if we have a lot of features and here also I want to emphasize that simplicity doesn't mean that our product shouldn't be like complex underneath but the stuff that we have on surface to our customers, what they see and what they use should be simple for them to use.
11:23
So if you have a lot of features, it starts to become clunky. So and again, if you have underneath the architecture, the really fashionable booth work right now is like microservices. So maybe it's better to divide the application for some smaller chunks, for modules, use the microservices,
11:41
switch it on, switch it off depending on the customer needs instead of putting everything to everyone and then make people confused. So this is one of the stuff that we should remember to ping. Another, if we have too many stuff, people are basically lost. Ask if you have too many road signs.
12:02
Again, if we have a lot, then the complexity grows and basically it grows together with the number of the features and it starts to become clunky for us because maintenance of code is quite difficult in that case. It means that probably there is no one who remembers what was in the code
12:23
and why something was implemented as well because it was a lot of stuff, a lot of discussions. Sometimes the complexity also it's connected with like really not having any documentation or if the documentation exists, it's not updated or there is like thousands of pages
12:44
who basically no one just no one read it. So it's like really hard to maintain if we have a lot of features. And our users themselves, there is always a point when they're like happy or they always will want more. So this is for certain but this is also worth to remember
13:04
that if we add too many stuff, they won't be able to find anything. They will be confused. Even if we have excellent UX designers, we just make their life really tough because designing for stuff that have like multiple features, sometimes it's like really, really hard.
13:24
What else? Obviously, if we have application that exists already or there is like the new application, we have a backlog. By backlog, I mean the ideas for the future. So obviously, we should have some kind of the roadmap, so ideas what we should deliver in the future
13:41
and if we have really long wish list, we start to create something like commitments. So why commitments might be bad? Well, if we are living in a world where application are connected, so there is like almost no standalone application, maybe like not but standalone, maybe not anymore.
14:04
So we are integrating with other software and then just imagine that we committed that we deliver something in 2017 and some other people are waiting for that. It's like a ridiculous timeline, first of all. Another thing is that we cannot react for the changes that are in the industry.
14:22
Let's say that we have application for payments and I think that year ago, no one would thought about Apple payments as the thing that will just be on the market or like fingerprint login two years ago, right? So if we have like three years roadmap in the future, we cannot actually foresee what will be like trendy in 2018
14:45
and if we are having the application, we cannot squeeze in our plans the new features that are hot on the market. So if we have those commitments and then sudden innovation comes around here, we can all break our commitment and some other people will be screaming for us,
15:02
oh my God, you didn't deliver or we are just apply and we apply the new thing or we just postponing applying new things for later on. So this is the kind of question we should answer. On the other hand, if we don't put those things with the commitments and we've done a huge roadmap,
15:20
it's easier for us to be flexible. Modern world and people just usually use the word agile everywhere. So how many of you know something about agile or heard the word? Okay, I see majority but there are not few hands up. I don't know if you are sleeping or you don't know.
15:41
Basically, agile is the methodology of doing the software in a really flexible way, taking care of changes and basically being able to adapt to the changes. So the hilarious thing in the companies, everyone obviously use agile and I also see in the companies that use agile
16:02
that we have the roadmap commitment and scheduled releases for five years ahead and they say, oh yeah, we can adapt. And then we figure that, oh no, actually we don't because we have commitment. So guys, if we have shortened the list of the wishlist, we can then adapt. Okay, backlog itself.
16:21
So if we have really a lot of user stories or backlog items or whatever ways you are having the requirements, you have no clue what is inside. And especially if it's like just imagine that this is like backlog for five years ahead. Maybe there is some kind of prioritization
16:41
that is more guessing. Probably you need like not one person but army of people to manage that and just review it and just update it and just figure it out if we still want to do it. And again, going to the example with payment application or banking application and any other application that want to do something with like fingerprint.
17:02
Just imagine one few years ago the fingerprint was the thing and we actually, oh no, we can't do that because we have the road map. Also I think that PayPal implemented the fingerprint log in like December last year even though fingerprint is at least one year and a half
17:22
available in the market and they have like the banking application that did it really, really earlier. So as well from our consumer perspective, if we have like some break from the market which is really innovative and we don't deliver basically it means that we are losing slowly the market.
17:40
So that's why it's important to keep it lean. Obviously if we have this, what we can do? I would just advise to delete it but people usually are terrified when they have it. No, they are our customer's requirements. We cannot delete it. But well, if no one knows what is here,
18:03
it's the best way. Maybe instead of deleting, you were really afraid to just put it somewhere like some backlog, some separate backlog or maybe Excel spreadsheet because everyone loves Excel spreadsheets and just don't see it like on the daily basis. Try to figure it out how many developers you have
18:23
and what there is like the needs for the current and the next time box. By time box I mean if you use sprints, use sprint. If you use Kanban and you have like timeline that you are delivering something every week, use those weeks. Depending how you're developing software,
18:41
just figure it out. Okay, how much time do you have and plan the things only like one or two time boxes ahead and figure out how many backlog items you need. Why not more? Because then again, as I said, we start to having the problem with validating. Obviously, having like backlog with 500 user stories
19:03
can be valid if we have 20 teams with 10 developers each, then probably 500 user stories is the correct amount that we need. But if we have the team of five developers working on something, then 500 is definitely too many.
19:22
Okay, another thing. As I said, priorities in stuff like that are really hard to do because, well, we are guessing. Another thing is that documentation. I said a few things about it,
19:43
but basically, especially if we have a lot of features, we just end up in having like nonsense documentation. I'm not saying it's not important. However, it's better to keep it light. All things that we are writing down probably will be outdated like minute later we finish.
20:02
What I advise to do is having like diagrams, having automated tests as a part of our code as well, just to make certain that after five years, when no one bothered to read the documentation and we want to change something, we have mechanisms that actually say, oh, but you brought the different part of the application,
20:23
you even didn't change. So probably there is some dependency no one even remember. Obviously, some documentation for users is a different matter than the development documentation. Keep also descriptions from like user stories
20:40
or backlog items somewhere. Once you finish, don't delete and forget, but keep it somewhere when you can basically reach them. Some nice mechanisms also are in code to plug to the user stories so you can use that as well if you wish. As I said, I prefer automated tests because this makes us a bit of a safety
21:01
that once we change something, there will be something that probably will tell us, oh, the rest of the application is like dying because of your change. Quickly recapping what we were talking about, complexity from UX perspective is like disaster. Complexity of code and managing the code itself
21:21
is really problematic. And obviously, our users are not happy as well if they don't see the features that they like and they basically start to struggling with using the application. Actually, I could name a few error per systems here that are like that, that are really huge,
21:40
really overweighted and people are struggling, but they are still buying them. So maybe there is some kind of a good model business there. Roadmap commitments and too-big backlog, on the other hand, is like the problem for development side because our customers think that if we committed to deliver something in 2017,
22:03
it will be done. And then if there is like new shiny thing and they want us to deliver that as well, they think, oh, but you committed to 2017, so you deliver that and on top of that, the new feature, right? Obvious. And sometimes they're struggling and understand that it's not working that way.
22:21
Okay, so what we can do? We can clean up, so this was the takeaway, so my favorite part, I hope that you like it. But before that, also we maybe speak a bit about estimates. How many of you heard about estimates? I hope everyone.
22:41
Excellent, everyone. How many of you use estimates? Okay, there's a few people who don't or who sleeps. Okay, so yes. And how many of you heard about story points? Excellent. T-shirt sizes.
23:00
Okay, t-shirt sizes is like the matter of estimation that they like story points, but instead of story points, we are using SML Excel. Okay, cool, so I can continue. So one of the ideas that may be tempting to like reduce the scope and basically start to speaking
23:21
with the customers about thinking about their wish list and trying to reduce the scope is like using story points. And some of us are like tempted to say, okay, let's give the really high estimates. What will happen?
23:41
The story, really recent story, I was on estimation session where the highest estimate was 55. So it was like, guys, it's like mistake because people won't understand. When you're then chatting with the business, for them there are numbers.
24:00
Probably they have magic Excel spreadsheet that will translate it for anything because those are numbers. The same happens with the t-shirt sizes and with everything. I'm not saying that estimates are wrong, but really they are like misuse. So you need to really work closely with your business partners to make certain that they are understanding
24:21
what we are talking about here, what the estimates should say, and that estimate doesn't mean that we deliver something next week. Okay, so why estimates are not working? So first of all, as I said, our business partners don't understand story points and really I've seen a lot that we, I mean development side,
24:44
just throw the story points for them and say, okay, this is big. You can decide to build that, but well, it's your case, right? And they don't understand basically that story points, it's not time, it's not money. It's also like complexity, it's also risk. And they don't understand that maybe if something is big,
25:02
it's not because it's like time consuming. Maybe it's just risky and then basically means that we break the whole application apart and basically it felt like the kitten I showed you. And again, if we tried this approach, so this 55, which is like hilarious number,
25:21
but let's say that we have more normal numbers like 13. So we give few times 13 as an estimate, that business will start to think, okay, they give the huge estimate, but they delivered. Well, that means that basically it's just the numbers as we assumed and it doesn't mean anything.
25:41
So we can keep continue at features though. Sometimes, as I said, they have their own excels. So as I said, spreadsheet makes the magic and they translate it to their own terms and saying, okay, yeah, that's fine.
26:00
And last but not least, they don't know that basically this estimate can actually reflect that this is not beneficial for customer. Again, sometimes when we are doing the features, we see the technology side that it's not visible from the business perspective. And sometimes businesses see the stuff that we don't see
26:21
because we are not close enough or even if we are close enough, we just sometimes underestimate their ideas. And this is kind of the battle and what we need to bring to our world is like trying to conversate and understand each other. Throwing story points is like mistake
26:42
because it's not bringing the conversation and this is the problem here. Because maybe if we speak with the customers and they say, okay, I have this new brilliant feature. I'm the bank. I need to deliver our customers amazing mobile app. And let's say that there are times when the fingerprint is just new
27:04
and basically business says, oh my god, this is this beautiful fingerprint login just implemented. But if it's new, we don't understand the technology and for a really big number, they don't understand that this is because, okay, we don't know the security issues because it's new. No one never did it before
27:21
so we need time to investigate a lot of stuff. And there's like bunch of other stuff as well. So this may mean, okay, this is big but this is really brilliant idea. We want to do it because it's like cool stuff but it's like risky as well. It also can be like our bank. We say, oh, we have this brilliant idea.
27:42
Let's apply like Hangouts or Messenger in our banking application or something like that. And then you think, okay, but if people have messengers and stuff like that in other tools, why the hell they will need to use our banking app which the purpose is something different, right?
28:02
And it's like difficult for us because we are not prepared for doing that. There are a lot of security issues because just imagine that banking app, you are logging to your banking app and then you stayed logged in in order to deliver instant messaging. It seems a bit insecure. So there's like bunch of stuff like that
28:21
and we throw the estimate, okay, maybe they will be scared. So you see Storypoints actually doesn't show a lot. Okay, so when we want to clean up, we should do it, right? So how to start? Roadmap. So in the beginning, you can have an impression that roadmap is bad thing
28:43
because we have those weird comments meant and stuff like that. Actually, it could be a really good idea to have a roadmap but not in a linear way. If you have linear roadmap, people tend to put dates beneath even if you don't give them estimates, even if you say it's not any kind of the commitment here
29:05
if you put it in a line, someone project manager or someone from the business or anyone just try to figure that, okay, let's put the dates, let's put it in the calendar. And then we start to have commitments which starts to be scary and really problematic.
29:22
What we can use is a product tree or there's a bunch of other stuff I recommend to look to the innovation games. It's like a book that gives the idea how to make the things in a bit different way that we are used to. So what we have in our product tree, we have like two indicators of time now,
29:43
so current time box and future. We don't say where future is. It's not the line so no one will put here a calendar or maybe if we are like really creative, maybe someone can fit the calendar in that shape. I haven't seen the calendars like that but well, who knows?
30:01
Business sometimes is really innovative. The leaves symbolize the features. The branches are like modules or categories or kind of the groupings that we can use. So how we can have something like that? If we have existing software, the branches can be existing modules and we just add the features in.
30:22
If we're doing the brand new software, we first need to figure out what are the branches and then try to put the leaves and obviously change a bit during the meeting. We have everyone involved. So what we are doing? We are preparing that in order to make the meeting clean,
30:40
sending out the proposed features and proposed shape of the tree to people and then gather them in one room or one call if we are like working remotely and starting to discuss. By everyone, I mean business and IT. So the main stakeholders. If we are working in a software house
31:01
and we don't have direct access to business, we need to include product owners, marketing people or sales people that are responsible for the product for visibility. It means that it's a really huge meeting and in order to make it productive, I recommend to use post-its and stuff like that.
31:22
So not electronic ones. So you are literally moving the post-its and discussing, okay, what is the current time box? What will be next and what are the features and what are the stuff that we are doing? This allows us to first of all understand and start conversations. So the stuff that basically when we are throwing the story points to each other
31:43
or any other estimates doesn't happen. And then later on when we try to figure out what we actually need to build, we have at least understanding. Another part is because it's not the end of our journey. It's the first step. So once we have this, it doesn't mean that, okay,
32:01
now we implement everything that is now in the now part of the tree. No. That means that now we have to figure out what kind of value it brings to the business because, you know, the wish list is always nice, right? But then we need to think, okay, if within three months or a year or whatever,
32:22
our investment will return. So our development efforts are actually worth doing the stuff. I call it love versus ROI because obviously money are important for our business. Even if we are working in charity, we need somehow to survive. So somehow or it's like earning money or saving money.
32:44
Love is the one thing that you care about as a company. It could be performance. If you are building the search engine, you probably really want to have excellent performance. Or if you are like building the application for thousands, millions of users, maybe usability and kind of look and feel is the most important for you.
33:04
So depending on your context, this is the stuff that you are assessing too. So you're taking the list from the tree and one by one trying to figure it out together with people in the room where on the line the feature is. As I said, it's the feature level, not the story level.
33:23
So it's not yet detailed. So this is like an idea. It could be really big. We'll discuss it later. Okay, so we are assessing that. When we finish, basically what you can notice here, those are the stuff that our business cares the most
33:40
and this is the money that we care about the most as well. So we can name it like minimal variable product obviously, but then we can apply like common sense. If there is like, let's say, making secure login somewhere here and we have the customer data and stuff like that,
34:03
even though it doesn't bring a lot money and it doesn't influence anyway in our performance, we should take it in the consideration for the development because if we don't have secure login, then basically someone will steal our customer data. We are just basically risking a lot.
34:21
So always remember that stuff like that are useful as a kind of guideline, what we should bring, but then apply common sense and take the stuff that are also required from technology security or business perspective, but may seem that they are somewhere lower in the priorities. Again, how it can look with Post-its,
34:42
similarly, and then you can easily like reduce the scope as well because basically what we are doing is here and the rest is like waiting outside in the tree. Okay, so we have the candidates, so we have the features that we would like to build. We have a rough idea about how important they are for the business.
35:04
Can we have other metrics? Yes, here when we start thinking about should we deliver it or not, also the stuff that we are not doing, we are not validating our hypothesis. What I proposed having, again, high level, not numbers
35:22
because if we have numbers, then someone will use your numbers. This basically means that the feature will positively influence our application. This, that, it doesn't. So what we are doing, again, taking the subset of the stuff that were in the top corner and trying to think,
35:41
okay, what will happen if we add this feature? So again, having an example, let's say that we have, we are building the engine for booking the tickets or already we have the engine for booking the airplane tickets and there is like new feature connected with integrating with new Shiny database where there are like the additional data available.
36:04
So one of the additional data available is the color of the seat. Let's say that airlines keep some stuff like that and you can feel, oh yeah, it's a cool feature to have the colors of the seat or color of the aircraft. But how it influence the performance? And then you start thinking, okay,
36:21
what we care about is like performance of searching. So if someone search for flight and wants to request a ticket, we need to like bring data really quickly. If we have another join with some kind of new Shiny database, how it will influence our performance? So if we hear word join, at least people who do the joins,
36:42
you can feel, okay, join. So that's something that can be slow, especially if we don't know this new database and maybe there is like connectivity issues or other stuff or if we have data in our cluster, then maybe there is no connectivity but there is join. So we can slow down.
37:01
We don't know what is one of the hypothesis. So maybe it's not this excellent idea. On the other hand, maybe we have another feature that it's like, again, bringing data inside the one cluster instead of having it distributed. And it seems, oh yeah, maybe our performance will be better if we have it like reduce number of joins
37:21
and just put it in the table, in the same table. Maybe it's a good idea. Maybe not. But this is like the kind of we're trying to assess and validate against the business features that we care about. Best way is to take like three things that we care.
37:41
So again, could be performance, could be usability, assess if the feature makes sense or not. If there is, and then we can have a clear answer. If we have the four things that we are carrying, and we have two and two, we cannot really decide. And then if we have the odd number, always we can decide.
38:01
If we start to have like five things, the complexity grows and we just waste time, sorry. I'm really fun of having like high level stuff instead of detailed numbers because then in the end, reality will assess our assumption anyway. So we can be wrong. We probably are wrong.
38:20
So that's why it's good to use it like really high level. Okay, but what in the case that we really must use estimates? And we really used to have numbers. So here we can also bring this really obvious stuff. So ask business, okay, could you estimate as well?
38:40
Could you give us the business value? And also add the risk to our estimations. So again, go back and have like an example. So let's say that we have banking application again. And again, we have the login. And let's say that we have a story that we should implement new way of logging.
39:02
Again, but fingerprint, but not only devices like phones, but also like computers because they also have fingerprint. And it's like big and we don't know why. So if we assess it a bit, so try to think how we can basically see that.
39:22
Okay, why it's big is risky. We never done it before. Let's say that fingerprint is really new. No one heard about it. We don't know how to apply this, if it's secure or not. How about keeping the data in the phone? A lot of stuff like that. But on the other hand, we know that, okay, our customers are lazy.
39:42
They don't remember their passwords because they are complex because this is banking application, so the passwords have to be complex. And we have a lot of requests on daily basis about can you have my password back? Or can you send me the password and stuff like that? So our business say, okay, but if we have it,
40:01
well, people won't forget their fingerprint, right? So the number of forgotten passwords should be reduced and everyone will be happy and this is really innovative. And maybe we take some customers from other competitors because of this. And actually, I changed my bank when I arrived to the UK when I found out that it didn't have fingerprint
40:21
because when I lived in Poland, our banks have like the standard login by fingerprinting. So when I arrived, choose the bank. If the application didn't have fingerprint, I just choose the bank which enabled the fingerprint login. Kind of stupid thing, but if the apps looks the same,
40:41
small stuff like that can matter. So just imagine in your context of your application where you are doing that, if you have really innovative thing, how it can influence your customers as well. Okay, end of topic, going back. So this is the user story, this is the estimates. What we can do with that? We can also think, okay, maybe we can do it slightly different
41:04
so maybe there are some alternatives. So instead of having fingerprint logging absolutely every device possible in the world, let's focus first on let's say iPhones and then maybe we can bring everything else. So a prim, let's say it's iPhone.
41:22
It's smaller risk because it's like only one device instead of everything that have fingerprint and the business value is slightly lower, but also we can think, okay, how many people will actually log into the bank on the computer using fingerprint? Sounds kind of strange.
41:42
So maybe it's not that important and we can divide it and reduce it onto the phone only. Okay, or maybe we have some other story which is let's say logging by voice recognition. Sounds to be like really nice, it's risky,
42:00
but then you see, okay, the business value is quite small because we say, oh, no, basically, well, maybe it's like nice, but who would like logging like that? It seems to be secure in any kind of way even for the business users so maybe it's like not even worth to doing that. So this also if you just then start to comparing stuff
42:24
allows you to make the informed choice. If you have like only one number and don't have like any point to make any argumentation, you can't basically decide. And here you can see, okay, aPRIM doesn't have like everything, but it's like sufficient for us.
42:43
So we can put like explicitly needs that are delivered by the user story from the business perspective or from the user perspective and start to compare and then make decision which is like, as I said, informed and easier for us if we see it.
43:01
I recommend it to do stuff like that, especially if you have features that you like argue a bit with your business partners and really don't want to do because then maybe we can find together alternative that is basically good, fulfill all the needs, and it's simpler.
43:24
And remember, adding the recommendations, especially if you are like in a corporate world where you live with emails, then recommendation is crucial because if you put the table, put the numbers, people can not understand what you basically want to sell them.
43:42
Okay, and now my favorite part, last one, deleting. Well, I'm not certain if people in the back can read. Can you see it actually or not really? Yes, okay, cool. So in our software, we have a lot of features that we don't use,
44:07
especially if our software is few years old. If we start developing something, then it's high probability that it's still not really overweighted. And I noticed that especially if we have already a customer
44:22
who is like external customer, not our internal customer, who are really terrified to remove features. So what happens later on? We obviously grow, our application grows, complexity grows. We know it, everything, because I told it before, you probably notice it in your own experience.
44:45
People are basically terrified to delete anything. And not even speaking about from the technical perspective, from the business perspective, just imagine we are working software house, we have the salesperson. The salesperson did his PowerPoint five years ago
45:02
and present the feature, and then suddenly the feature disappears. Come on, you are in the presentation with the customer, you are presenting this beautiful PowerPoint, and then you try to open the application and you are shocked. Oh my God, where is the feature? This is probably bug. And then you discover, oh yeah, we remove it because we discovered.
45:22
You know, we have like, you know, the salesperson, we have these really nice tools that measured how many customers are using the feature, and we discovered that none of customers are using the feature, so we just remove it. And we have continuous integration, so we remove it like instantly, that's why you don't know, right? In less ideal world when we don't have continuous integration
45:43
and there are companies like that, when we deployed every once a year or something and we just removed a lot of stuff from application, it could be even bigger shock than discovering that one feature disappeared.
46:00
Okay, so what first we need to do? We need to bring some kind of certainty. So first, obviously, as I mentioned, measuring if customers are using feature or not. If we measure, also like, we need to talk with other people. So if we have marketing sales, product owner, we need to inform them and say, Hello, we have the idea.
46:22
The idea is to remove something. Then they have like panic attack. Oh my God, what will we be selling if we want to remove stuff from application? You know, we need more, not less, because we want to sell. So again, then their conversation starts, and what we can basically can prove that if we start removing the features and making application lean,
46:44
also it will positively influence the performance so our customers won't be like calling them annoyed that, you know, application hangs and basically doesn't meet any kind of non-functional requirements they have connected with performance. We can add new features, we reduce a lot of stuff like that.
47:03
And also we need to think a bit, Okay, if I'm like sales or marketing person, what do I care about? They're obviously caring about selling. So if we present to them those metrics, we also need to present them in the way that will be tempting. So saying, Okay, this is the nice new performance.
47:21
So when you show the demo to the customers, it will be nice and sleek and basically it will be really smooth experience. You won't be like embarrassed after clicking and then waiting a minute to reaction of our software. So actually there's a lot of benefits for you as well. So, but remember uncertainty causes fear.
47:42
So if we don't know what we are doing and we just saying, Okay, we delete it and we don't support it anyway, people will feel insecure. So also one of the remedies for giving some kind of level of security is adding automated tests to our software.
48:02
Work in a company that has around 70% of coverage and it was brilliant. Work in a company quite recently that have no automated tests. Everything is manual regression and I have to say that each change and changes are done every two weeks.
48:22
It's a nightmare and there is like really nightmare because there is no certainty that we even don't remove anything. Just adding stuff is like dangerous and because we don't know what will happen, we can obviously suspect we are manually testing but it's a nightmare.
48:40
So if you have the environment with no tests and we'll start speaking about deleting the code, think twice and really think if you will be able to prove the software is still working and all the dependencies that you even don't remember that exist are tested properly. So as I said, measure if we can delete if someone is using
49:03
and make the tests. Again, story from one of the companies I worked in, it was internal IT department. We were measuring how basically our users are using application. This was a kind of the reporting tool and we find out that there is a feature that no one uses for three months
49:22
and we decided to hide it. We hide it for like another three months and then it was like the Christmas period of time when people were doing their reports and then we had the code from accountants with, oh, hello, you know, we had the nice button there that we pressed like once a year to have the report
49:44
and I can't find it, you know, do you know where it is? Fortunately, it was only hidden so we unhidden it, the button was there, so lesson learned. Remember also the context of the feature that you are measuring. So sometimes people don't use it like for majority of the year
50:02
but this is the one special time when they really need it or at least they assume they need it because maybe there is a way to make it more intelligent so maybe some kind of custom reports that are used more frequently than once a year. So instead of like assuming that, okay, no one just speak about this like half a year, just remove it,
50:24
better to clarify, okay, when is the period of time when the users potentially use it because our measurements can be wrong because simply the period of time is not suiting the needs. I think it's especially important when you have retailers
50:42
while obviously like festive and stuff like that are obviously heavy used and then a lot of features is like slowing down because of the period of time. So remember that. Okay, so again, recommending removing the features if you can because it simplifies everything.
51:02
And now quickly wrapping up because I see that I almost ran out of time. Basically, if we have too much, it's complexity grows. We have the problem with UI. We have the problem with the commitments. Instead of one person to manage backlog, we need an army.
51:20
And also I think it's worth to remember that backlog is not a ready product. Tests are not ready products. So what we care about is obviously having a working product. So even when I was talking about automated tests, I don't mean that we should replace our development efforts to write beautiful tests and have everything covered
51:41
instead of having a product. It's something additional that helps us. So what we can do in order to help ourselves, we can have non-linear product roadmaps that will help us. We can start to think and discuss prioritization in a slightly different way.
52:02
So adding to our usual money, adding the context of our application and stuff that matters to us, have really high-level estimates that are not numbers because then we have the access pressure and all weird things.
52:21
If we really need to put the numbers on, just remember to have some kind of additional stuff there just to bring the meaning to the numbers. And also remember that if there is something that you strongly disagree with, maybe there is an alternative that is better.
52:40
So propose it and start discussion and maybe we can, together with the business, figure out a solution that is really the best for the application. So I hope that you liked the presentation. I encourage you to vote afterwards for positive feedback. And do you have questions? Because I think we have still time.
53:04
Now I already feel back on the exam. Okay, I don't see questions. I'm here during the day. So if you have any questions, feel free to catch me. Also, there is contact details. So feel free to contact me as well.
53:21
Thank you for your attention. Have a lovely rest of the conference.