440 karma · joined January 11, 2009
Many of these dependancies are open source. Nothing prevents you from copy/pasting the code and then maintaining it yourself. Then you alleviate the "hard to change" problem and you can vet it thoroughly inside your own team.
Just sayin.
Disagree only in that you need some rigidity for some time in order to get consistency and value. Agile dictates that this time-boxed rigidity should be routinely inspected and adapted over time. Does that make sense?
More of my views here https://leanpub.com/agileforleads/
But the process and team environment that I'm encouraging in the above playbook will attract and keep the best team players. At least, that's been my experience.
The book is also Free.
It's hard to encourage adults to try to learn new things. Myself included. I hope that by reinforcing learning and experimenting with my children they can have a higher tolerance to the fear associated with 'starting'.
Some random thoughts:
* I think failure is glorified in a way that is not healthy, particularly in the startup field. Try to optimise for success https://signalvnoise.com/posts/1555-learning-from-failure-is...
* Like you, I'd like to find the right/correct answer but lately it's the context that's more important. Helping my boys put this int practise would be valuable I think - more-so in human relationships than STEM pursuits.
* If I can humble myself to learn how to learn about someone else's point of view, rather than attacking and trying to pull them around to my view, then I'll be setting a good example to my boys. I don't what them to think they have to agree or even tolerate other's points of view, but they should respect that someone else holds something different, even (especially) when they don't agree with it.
* I'd also like them to build strong convictions to what they believe. I'd like them to use science and evidence to support things but at the same time, many things in life that are important, have to be taken on some measure of faith - I'd like my boys to have the resolve to choose a foundation they agree with and resist external influence if it's very important to them.
Also consider whether you really need a test: https://robdmoore.id.au/blog/2015/01/26/review-of-jimmy-boga...
Same issues right? Complexity === pain and we can't seem to grasp this as developers. Are we the most self-flagellating people on the planet?
I have used JIRA, TFS/VSTS, Trello and other in production on various products so this opinion is based on years of experience and pain with the 'wrong tool'.
Here is my verbatim section entitled "8.3 Estimating a Story". Be sure to take take this in the context of the whole process and tooling, which is covered in detail in the ebook https://agileforleads.com/
>
Remember how I said that if you only take one action from this course to your team it should be the Retro? Well, the second most critical action to your #agileforleads process is the Estimation; specifically consistent and repeatable estimation. Sometimes this is called Backlog Grooming or Backlog Refinement. Those terms don't work for me because they suggest that it's kinda optional, and for us, it isn't. Other teams call it "pointing [a story]" and you'll see why below.
Not every Agile process will be scientific. Many of the common agile patterns don't need to be. Scrum practitioners will generally apply the following but, as usual, I'm going to refine it a little more for you so that it's not only easier to use, but substantially more valuable.
Don't get stressed or hung up on being careful to ensure that you pull off estimation activities "by the book" because I've said it's so important. Just carry these tips with you and try to throw a new one in each time and eventually, over time, you'll find a consistent groove.
Being able to reliably predict future delivery rates based on historic delivery rates requires control. Controlling the inputs ensures more accuracy for the outputs. It's just science.
The rules for our estimation are the following:
* We use "points" instead of hours or person-days. Our points are a Fibonacci sub-set: 1, 2, 3, 5, 8 and "too big".
* We use Planning Poker for "throwing down a number" and we use our hands to do it. Avoid apps and playing cards if possible. Like the Retro voting, we don't reveal votes until everyone has silently selected a number. Everyone reveals together.
* When there is only a single size difference (eg. min is 3 and max is 5) we "go large" (select the 5).
* Use all 10 fingers to indicate "too big" and as early as possible, break these down into 2 or more smaller stories.
* When there is wider deviation, a "low ball" team member gives reasons for their low vote and the "high ball" member explains theirs too. Then discuss.
* Limit discussions (strictly 2 mins if you have a lot of stories to estimate; use a stopwatch) and invite a second vote to zoom in on a number. Two, maybe three, rounds of voting should be enough to get to the same number or a single size difference. If not, split the story or create a Chore to investigate the requirements further.
* Log blocking questions for the PO, update the AC/this is done when as you better understand the story, and add notes/reference links to the description while you're discussing the work.
* Log the agreed estimate/points number at the end and quickly move on to the next story.
Have a look at the following scenario and then after, I'll unpack some of the details.
How-to: Simple Story Estimation using your hands
Team estimation need not be a formal ritual. Two developers at a desk is enough. On other occasions where you want to move quickly through many stories (you've just cut up a large block of work and the PO wants a date), booking a meeting room with a bigger selection of your team gives everyone focus, and increases the accuracy of estimation.
1. Gather team members together.
2. Open up Tracker and expand the story detail (so the title, AC and any attachments/images are clearly visible) so everyone can see it.
3. Invite someone to read aloud the story and it's AC. Show larger views of attachments. Someone could summarise or add a little more detail verbally if that helps.
4. Ask members whether the story is clear enough on it's own for everyone to "pick a number" (silently). If not, ask and answer questions for a couple of mins and log questions down for the PO that the team can't resolve on their own.
5. When members "have a number", ask everyone to hold up closed fists and count backwards from 3 to reveal votes simultaneously. "3. 2. 1. go!" Single finger for 1 , 2 fingers for 2 , etc, 8 fingers for 8 and all fingers for too big .
6. Jen votes 5, Alex 2, Kate 3 and James 2. Since she's high, the facilitator asks Jen "why the 5?"
7. Jen, who got caught up seeing the css and js note explained a concern which the other team members quickly identified as confusion. Once the issue was clarified Jen exclaims "Oh! Sorry, I'm a 2 then as well".
8. Another member asks "So go large then?"
9. And the rest of the team agree. The facilitator logs 3 as the estimate and open up the next story.
I know this example doesn't cover all the scenarios and variables but I'll try to cover many questions I hear frequently and some of the more common variations.
* Let's start with story points. Developers are notorious at estimating very inaccurately when it comes to hours and days. Just ask any project manager. It's also a recipe for bias too - I want to show my team and myself that I have a handle on something and I can do it (quickly), so I'm mentally incentivised to offer a smaller than reasonable number. Most developers often estimate by a factor of 0.5 or smaller when using linear time. Points push all that to one side and free a technical team member to think more clearly. We usually say that points are in terms of "relative complexity or effort". Complexity works for some personality types. Effort for others. The other thing to note is that a 2 is not necessarily twice as much as a 1. Think of 1, 2, 3, 5 and 8 simply as containers. 5 is the "middle of the road" container and 1 is the smallest thing the team will ever do. In that "1 container" might go a one line change that takes 10 mins or a re-styling effort of 3 hours. But it's the smallest so the smallest items of relatively the same size get a 1. 8 on the other hand is absolutely the biggest thing any member of the team wants to commit to in an iteration. If your iterations are 1 week and Bob thinks the story can be done in a week but Sarah thinks longer, then it's more than an 8, and should be broken down.
* Less tools is more. Avoid the Planning Poker cards and apps and just stick to your hands. This also influenced the selection of Fibonacci numbers. We don't use the size 0 because it's somewhat confusing and dangerous (like a Chore - more later). We don't use more numbers because you get diminishing returns by increasing the resolution of estimates too much further. Tracker also offers "t shirt sizes" S, M and L which I've found helpful for planning heaps of work up front very quickly but not particularly practical for day to day work or new teams to this process.
* At all times, remember: we're just estimating. I'm preaching to myself here. I often have to remind myself that these are all just estimates. It helps you relax a little and not apply as much pressure to yourself (and your team mates) and sometimes get to a number quicker.
* Use the Done column to reset your base of reference. I didn't include this in the narrative above because if you're estimating regularly (every 2-3 days), each team member subconsciously knows the relative scale of each point container. But on more occasions than not, it's helpful to pull up the Done column in Tracker and refresh the team on what each size means, using recently completed work: Scroll to the bottom of the Done column (most recent completed iteration) and work back until you find 1 or two of the various sizes that the team is debating match the container for the current story being estimated. This is another mechanism to ensure consistency over time for the estimation inputs. You're essentially reminding each team member "what a 3 looks like" or "what a 5 looks like" prior to each silently forming their estimate. This historic reference is vital in ensuring that work of the same relative size receives the same estimate over and over again.
* PO does not vote. After a story is defined, the developers usually estimate it. Sometimes other members of the build team can help but this activity must absolutely exclude the PO. The PO has a conflict of interest when it comes to estimating how big a story is, so they need to stay out. If your PO can sit in on the discussion to answer questions and further clarify, then that can be helpful but I've found they often influence the estimate, sometimes simply by being present. If you can find a way to meet with the PO and clarify the AC separately and estimate without the PO, I think you will have more success. Discuss in your Retro if you have issues.
This, like many practices, simply gets better over time. It's ok for it to be little slow at first. Like commits, stories, iterations and release phases, the smaller you can batch things, the faster you'll cycle and quicker you and your team will learn.
But IMO this tracks back to the MPA vs. SPA problem. Do we actually need to be using a SPA/JS framework (Angular, React, etc) and what do we get in return which outweighs the wildly agreed increased development effort of SPAs?
I think the author is referring to mainly "wrapped" SPA web apps that sit inside native apps with a "web view" rendering the SPA (like the browser would). It's not just wrapped apps tho, many native apps have some kind of hybrid where you're using a library directly (React Native?.. dives for cover) which but a whole framework of abstractions on top of the native interfaces. With so many "layers" and all these things being new and vastly more complex than MPA web apps, the statistical likelihood of goofing things up is just very high.
Where are the days of old (what? 10 years?) where we got to the edge of MPAs (we didn't even call them MPAs then) and optimised the crap out of them making them fast, and simple and quick and a pleasant user experience? I think we come up with all sorts of poorly justified reasons to go to SPA/JS frameworks these days and the users are the ones who end up paying the price.
But I agree with kchr in principle. "Burner" may not mean anonymous but it's more often than not associated with anonymous and anonymity. It's the go-to perception or association if you will.
So I think kchr and I are saying the same thing: the article is using the burner/anonymity context as a little click-bait IMO and it's not a big deal but it's a valid point.