Discover and read the best of Twitter Threads about #agile

Most recents (24)

Hey all #testing folk. I have someone in my team who loves working in #agile teams. But they're a senior tester, and they're not sure where they go next in terms of career ladder, esp as they're near the ceiling of what the role pays.
Part of me wonders if the answer to this is moving away from treating salary as hierarchical silos, and looking more at the person and what they contribute.
Hey @threadreaderapp can you unroll please?
Read 3 tweets
a quick thread about "sprints" (and #agile)

1) frequent integration (of ideas, code, expectations, perspectives, data, etc.) makes absolute sense. It works. There is an optimal tempo, and that point is lower than we intuit most of the time...
2) frequent integration will also, defacto, feel a little uncomfortable ... because *by design* it will expose disconfirming information, and will always feel a bit premature. Forcing functions are designed to make us pay attention...
3) we have to contend with a limiter...and that is our ability to actually make use of/process the information that the forcing function elicits. A long time-box will yield so much information, that it will be difficult to make full use of the information
Read 8 tweets
So, this is an important thing to grasp as #ux attempting to work on an "#agile" team (and explains why sprints feel too short). Chance are the team is doing scrumfall (right), and not thinking in terms of repeatedly revisiting the "design" in thin slices(left) ... (1/3)
...OR the team is doing a single "thin slice" and then being asked to move on (the ole MVP bait and switch). Of course, if either is happening, you'll naturally (and rightfully) rebel. With a story map (thanks @jeffpatton ) you'll be able to think about the big picture... (2/3)
...#ux has always been comfortable thinking in terms of increasing fidelity. The trouble has been that "shipping" = "done". With a story map, you can combat that by making sure each increment = valuable AND having an opportunity to improve/tweak (3/3)
Read 3 tweets
One of the biggest lessons I've learned about designing product organizations is how much structure impacts strategy.

/1 #prodmgmt #agile #growth
I worked with an organization that once had 6 levels of reporting.

There was a CPO, with GMs reporting in, VP of Products reporting into GMs, Directors, PMs, APMs. They tried to give everyone their own product goal.

It did not scale well. /2 #prodmgmt
By the time the goals got to the Directors, they were so granular a solution dictation that there was no room for the rest of the team to experiment, learn, or talk about value.

/3 #prodmgmt
Read 10 tweets
One thing which has been really bothering me lately is running up against folks who insist on defining "value" in the narrow terms of that which can be directly observed by users' eyeballs. Isn't #agile supposed to know better? A thread.
I'm legitimately confused about why anyone claiming to be #agile would be so myopic as to say that investing in the underlying technology platform, paying down technical debt, or training a team in a helpful technology is somehow less than "feature dev".
Don't they know that feature factories are bad? It's been my experience that an exclusive focus on "putting new functionality" in front of the user leads to a loss of product focus. It also destroys morale and leads to insane increases in technical debt.
Read 10 tweets
Seeing a trend in large (and not originally software based) companies making a move to more outcome oriented models and feature teams not understand that you need #prodmgmt leadership.

You can’t have a product organization of a bunch of entry level folks and expect magic. /1
What these companies typically want to do is move people from other parts of the business into PO roles on Scrum teams.

Totally fine. You can do that and train those people.

But who is pulling all those scrum teams together into a holistic product vision for the group? /2
Who is going to keep mentoring those people once the trainers and coaches you hired leave?

Who is going to align the business strategy back to the software strategies?

Read 6 tweets
Scrum clergy member (SCM): "Sinner, why are you not hold a scheduled retrospective after every sprint?"
Agile Atheist (AA): "Who says we do sprints"
SCM: "So when do you release working software?"
AA: "As often as possible"
Thread 1/n
SCM: "But then when do you refine your stories?"
AA: "Whenever we get new information"
SCM: "And what about your retrospective?"
AA: "Which 1?"
SCM: "The one you should have every sprint if you actually did them!"
AA: "We schedule 1when we feel the need which isn't very often since we retro every standup, every story refinement, every architectural discussion"
Read 6 tweets
Here’s a little thread about “feature factories” and what I’ve learned since writing about FFs a couple years ago.

At the end of the day it is about a *genuine sense of impact*. Problem solvers need that. It’s in our blood... (1/9) #design #ux #prodmgmt #agile
When you start out, getting something/anything into prod feels like a win. And it is! But with time that novelty begins to fade. You realize that anything in prod that doesn’t add some high multiple of value is just dead-weight (psychically, and operationally) (2/9)
You also become more tuned into success theater, which is like kryptonite to puzzle solvers. It feels dirty and wrong. It feels insincere (3/9)
Read 9 tweets
There were some clear themes coming out of the presentations at #productized in Lisbon yesterday about #prodmgmt and #design and #culture. Here is a brief summary of what I heard:
1/ Very little mention of #agile as a problem or a choice. It was just assumed by all speakers that this is the way everyone works.
2/ Solving problems, not implementing solutions.
Read 12 tweets
@RonJeffries I presume the #Agile Indu$trial Complex includes the people who roughly do this:

- "You should do these impossible things that feel weird and look silly."
- "We're not going to do that."
- "OK, then you won't succeed."
- "How do you know?"
- "...."

@RonJeffries Or maybe they do roughly this:

- "You should do these difficult things that feels weird and look silly."
- "OK, show us."
- (Shows them.)
- "Wow, that seems difficult, feels weird, and looks silly."
- "I know. Good luck. Here's my invoice."

@RonJeffries Or maybe they roughly this:

- "You should do these difficult things that feel weird and look silly."
- "OK, let's do all that together."
- (Does it together for several months, charging an obscene sum of money.)
- "Wow, that didn't seem to change much."
- "I know. Weird."

Read 4 tweets
So I've been thinking about the #Agile Indu$trial Complex 😀 as um discussed at length by @DanielMezick and others, and chatting with @chethendrickson, and I have a few thoughts and questions to share.
Imagine, if you will, that you're a somewhat ranking manager in a rather large company. You become aware of #Agile, through reading in Forbes or drinking with your fellow mucky-mucks, and you come to see that amid the hype, there seems to be some good happening.
You learn that the methods, and there are a lot of them, are all rather similar, and that they all offer greater visibility into the work, faster turnaround in response to your needs, and a focus, by the teams, on improving.
Read 16 tweets
Any imposed process, explicit (e.g. you must do standups) or implicit (e.g. you must do #agile) is likely to result in anything ranging from low performance to dysfunction. 1/
High performance comes from imposing enabling constraints (e.g. ensure we have a shippable product at all times, ensure we have a frequent feedback loop with the customer, ensure you are continuously improving), not process. 2/
Tell the team they can create whatever process they want, and that you will help remove any roadblocks. But take the constraints seriously, and make the team accountable to them. Show me the software! Show me how we're incorporating feedback! Show me how you're improving! 3/
Read 4 tweets
Like most IT people I love tools. And tools are absolutely vital to #Agile, esp. #automation of #development & #delivery. But when it comes to managing teams & processes, do #tools and #Agile always mix? Maybe not…
1. Software developers like #tools. No, they adore tools. They seem the most natural way to solve a problem, and they are familiar territory that any #delivery team is more than happy to enter. #Agile
2. But #tools provide little support for the *content* of most #Agile delivery tasks, from defining Product Vision to conducting Daily Stand-Up Meetings. They do support day-to-day workflow, reporting and recording, but at that level are often easily replaced by manual #methods.
Read 12 tweets
I often hear that the Scrum Master is "responsible for the process". Is that your understanding too?

On an Agile team, using Scrum or whatever other framework or approach, shouldn't it be the Team that owns the process?

#Agile #Scrum #Team
If so, why would the SM be the only person responsible? And if they're not, and the whole Team is involved, what is it that makes the role so special?

I'd like to hear your thoughts on that.

#Agile #Scrum #Team
My personal view on this - a Scrum Master is supposed to be a change agent. I am there to help everyone change the system of work so that it helps meet their needs.

This goes far beyond the "process" as such, and leads to better overall results.
Read 6 tweets
[thread]...Some two column tables. Apparently I enjoy this :)

(1/7) Our intuition says ... instead try
#prodmgmt #kanban #agile #lean
(2/7) What you say ... what they hear/think
#prodmgmt #kanban #agile #lean
(3/7) Evolving product manager role .... moving towards
#prodmgmt #kanban #agile #lean
Read 7 tweets
“How does #ux work with #agile” ?

Step 1: Read the Agile Manifesto for Software Development

Step 2: Read the Principles behind the Agile Manifesto:

Step 3: For a modern twist, check out Modern Agile:

1/3’ll quickly notice there is no mention of Product Owners, Sprints, User Stories, Story Points, Scrum Masters, Demos, Jira, etc. And no mention of #ux, #datascience, #businessanalyts #devops etc.

There is one key thing though... 2/3
Try as hard as possible to join a team as an equal member. The team is the unit of self-organization and inspect/adapt. Do the #agile thing and experiment with how to make #ux work in context. Harness agility to do great #UX

That’s it. 3/3
Read 3 tweets
Heard (again) that #design and #ux is somehow incompatible with #agile (which to most, means #scrum).

..that ppl can’t always jam their work into little increments

..that MVPs suck because they’re never improved

..that work can’t always be boiled down into a “ticket” 1/n
...that #design is more than screens...a more holistic view is needed

...that an output fixation is killing products

...that quality shouldn’t be sacrificed just to get stuff out the door

...that craft should be respected

...that #ux debt sucks 2/n
...and you know what? Those exact same things are muttered by engineers/QA all the time.

They have nothing to do with #agile, but everything to do with paint-by-numbers approaches to “delivery”, org silos, and overly simplistic “#design then build” models. 3/n
Read 5 tweets
There are many ways to inspire a “sense of urgency” that have nothing to do with estimates/deadlines.

#agile #lean #softwaredevelopment
1. First ... giving enough context so people give a fuck. That’s a start. Otherwise, you can’t expect people to “go the extra mile”...

#agile #softwaredevelopment #ux #devops
2. Let them STOP doing things that are less valuable. Nothing says “you’re free to focus and care” more than freeing people from context switching and multi-tasking.

“What would you like to stop doing, to leave time for this?”

#agile #softwaredevelopment #ux #DevOps
Read 4 tweets
I'm only halfway through Bertrand Meyer's 2014 book, "Agile! The Good, the Hype and the Ugly", but it's already proven its worth as a lucid, unrestrained appraisal of #Agile principles and methodologies. Here are a few passages that resonated with me...
"#XP's insistence that [pair programming] should be the absolute rule [...] makes little sense conceptually, as it neglects the role of programmer personality (some excellent developers like to concentrate alone and will resent having to be paired) [...]"
"Starting any significant software project (anything beyond a couple of months and a couple of developers) without taking the time to write some basic document defining core requirements is professional malpractice."
Read 19 tweets
Realized I had some posts that actually make sense as a series... a little blook

1/10 Moving beyond the platitudes of outcomes vs. is all a spectrum…

#prodmgmt #ux #design #agile #modernagile
2/10 Distinguising value and sequencing. Start with opportunities before getting bogged down in “LOE”…

#prodmgmt #ux #design #agile #modernagile
3/10 Prioritizing non-feature work and continuous improvement ... there’s value here too.…

#prodmgmt #ux #design #agile #modernagile
Read 10 tweets
So here’s an observation and question for the #scrum community.

One of the biggest issues I’ve seen with teams new to scrum is backlog refinement. Most people do it wrong and it has huge implications on #prodmgmt. /1
I have seen hundreds of teams treat backlog refinement as a two hour meeting where they rewrite user stories and estimate them.

While both of those are good things to do, they usually only do these two activities, instead of creating shared understanding about the work. /2
Teams don’t spend this time story mapping, discussing in detail, or contextualizing the end state of the product together.

Actually teams new to scrum usually don’t do any of those things. /3
Read 7 tweets
Almost every discussion I have that starts with “we need to go faster” ends with me asking the team to “define value”, and then do less once and work in smaller batches.

It is at this point that the reality sets in ...1/3
#agile #kanban #prodmgmt
... the reality is that the current system is optimized for:
-saying “yes we’re on it”
-keeping people busy
-brokering resource capacity
-keeping track of all the work in progress
-providing plausible reasons why nothing is shipping

#agile #kanban #prodmgmt
This should be easy to unwind, right? It’s math. Do less smaller stuff = go faster. Limit WIP ... discover/remove bottlenecks.

Well no. Because those optimizations run so, so deep. Reputations. Ego. Agendas. Promises to investors ... 3/4

#agile #kanban #prodmgmt
Read 4 tweets
We were looking for a way to do something different than our competitors who were focused on SEO. We decided to tackle sending people rental listings in slack. @davemastersnyc #agileux
We discovered it was too hard to install apps on slack, so we decided to keep the thread of the idea but pivot to FB messenger. @davemastersnyc #AgileUX
We learned that apps ramp up slow but they contributed to a top line organic audience AND repeating visitors to hit our goals! @davemastersnyc #AgileUX
Read 4 tweets
Banyak banget yang nanya, ngerjain startup tu asik ya? Gw share dikit ya ilmu gw di per-startup-an selama 13 tahun terakhir. Bakal panjang ya jadi sabar-sabar ngikutinnya
Gw yakin banyak banget di sini yang ngebayangin jadi kaya Mark Zuckerberg gara-gara nonton the social network. Bikin startup tidak seindah itu, apalagi jaman sekarang, PENUH PENDERITAAN. Iya lo ga salah baca. PENUH PENDERITAAN. Tapi bukan berarti ga asik kok sob nanti lo liat
Pengalaman startup pertama gw dimulai tahun 2005. Startup pertama gw adalah sebuat software house. Jaman itu masih ngenes lah. Kenapa ngenes? Itu jamannya masih kalo lo di bidang IT harus bisa jadi superman yang bisa segala macem dan dibayar serendah mungkin
Read 175 tweets

Related hashtags

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!